Skip to main content
Glama

Create project rule

create_project_rule

Add a rule to a project: when an issue enters 'status', append 'template' to its description. A rule appends its checklist to an issue's description when the issue ENTERS the rule's state — from the board, the Jira API or update_issue alike. The block starts with a hidden marker line '[//]: # (pm-rule:)'; while that line is in the description, entering the state again adds nothing (the journal says 'alreadyThere'). A [~username] in the template is a mention: that person is notified when the checklist lands. A checklist that would make the description too long is not added and the journal says 'tooLong'; the move itself still happens. 'trigger' says WHEN: 'entered' (the default — the issue entered 'status'), 'versionReleased' (a version it goes out in was marked released), 'subtasksDone' (every issue under it is finished — the rule acts on the PARENT) or 'subtaskStarted' (an issue under it was taken into work — the parent again); or what the project's repository said through its webhook: 'branchCreated' (a branch naming the issue was made), 'mrOpened', 'mrMerged' or 'mrClosed' (a merge request — a pull request on GitHub — naming the issue was opened, merged, or closed without merging). An issue is named by its key in the branch, the title or the description, and only this project's issues are touched. 'branch' narrows the three merge-request events to a request going INTO that branch, e.g. 'main'. Nobody is behind a webhook, so such a rule acts as whoever last saved or switched it on, whatever its action. 'deployed' fires when a pipeline reports that the issue went out to an environment (report_deployment); 'environment' narrows it to one of the project's environments by name, e.g. 'staging'. 'actChanged' fires on the issues that cite a legal act when its publisher's text changed, and 'actTouched' only on those where the change is in the place they cite (or that cite the act as a whole) — found once a week, only in a project with the «Legal acts» add-on; 'claimBasisChanged' fires on the issues that cite a claim ([thm:…], [claim:…]) whose legal basis is such an act, once per new text and claim; nobody is behind a publisher either, so these act as the rule's owner too. Only 'entered' has a 'status'; pass an empty one for the others. 'fromStatus' narrows any of them to an issue coming from that state: the state it has just left for 'entered', the state it stands in for the rest. A rule with action 'move' MOVES the issue to 'moveToStatus' instead of appending anything, and has no template (pass an empty one). The move is an ordinary one — made as whoever last saved or switched on the rule, asked of the project's workflow, written to the history with the rule's name, and followed by the rules of the state it lands in. A workflow that refuses it leaves a 'moveRefused' line with the reason in the journal and nothing else; 'moved' is a move made; 'tooDeep' is a move not made because rules had already moved issues three times off one event. A rule with action 'agent' is a DUTY instead: it says which issues may be handed to an agent role (agentRole, e.g. 'product') and what the agent may do with them. Its 'template' is then the INSTRUCTION — what doing such an issue means in this project — and nothing is appended anywhere. A duty may have no state (pass an empty 'status'): then an issue is handed only by a person. agentActions is a list from: describe, subtasks, ask, wiki, report, support, jira (propose a move or a comment in the project's linked Jira, applied by a person). agentFields names the fields it may set: priority, labels, duedate, or the project's own fields by name. doneStatus is the state it moves the issue to when done — never a finished one. capUsd raises what one task may cost, up to 5 dollars. Commenting is always allowed; finishing, deleting, reassigning and anything outside the issue never are. Saving or switching on a duty makes it yours: it runs on your behalf and access, and is switched off if you lose the project. The state and the type are NAMES of this project's own (list_project_rules lists them); an unknown one is refused with the list. Project lead or admin only.

Input Schema

NameRequiredDescriptionDefault
nameYesWhat the rule is called, e.g. 'Document pack'. At most 120 characters.
typeNoOnly issues of this type, by name, e.g. 'Bug'. Leave out for any type.
labelNoOnly issues carrying this label (one word). Leave out for any label.
actionNo'checklist' (the default), 'move' to move the issue to 'moveToStatus', or 'agent' for a duty. Fixed once the rule exists.
branchNoFor 'mrOpened', 'mrMerged' and 'mrClosed': only a merge request going into this branch, e.g. 'main'. Leave out for any.
capUsdNoFor a duty: what one task may cost, in dollars, when more than the ordinary ceiling is needed. At most 5.
statusYesThe state whose ENTRY fires the rule, by name, e.g. 'Ready for review'. For a duty taken only by hand, an empty string.
enabledNoWhether the rule is on from the start. Default true.
triggerNoWHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment, or 'actChanged' / 'actTouched' when a legal act the issue cites changed, or 'claimBasisChanged' when a claim the issue cites rests on an act that changed. For any but 'entered', pass an empty 'status'.
templateYesThe checklist, as Markdown: a '### Heading' per group, '- [ ] item' per line, two spaces of indent to nest an item under another, and [~username] on an item to name who does it. For a duty: the instruction.
agentRoleNoFor a duty: the agent role's key, e.g. 'product'.
doneStatusNoFor a duty: the state it moves the issue to when done. Never a finished state. Leave out and it does not move the issue.
fromStatusNoOnly an issue coming from this state, by name. Leave out for any.
projectKeyYesProject key, e.g. 'ONB'.
agentFieldsNoFor a duty: the fields it may set, comma-separated — priority, labels, duedate, or a project field's name.
environmentNoFor 'deployed': only a deployment to this environment of the project, by name, e.g. 'staging'. Leave out for any.
agentActionsNoFor a duty: what the agent may do beyond commenting, comma-separated — describe, subtasks, ask, wiki, report, support, jira.
moveToStatusNoFor action 'move': the state the issue is moved to, by name — finished ones included.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / trigger / description
      Previous value: -"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment, or 'actChanged' / 'actTouched' when a legal act the issue cites changed. For any but 'entered', pass an empty 'status'."New value: +"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment, or 'actChanged' / 'actTouched' when a legal act the issue cites changed, or 'claimBasisChanged' when a claim the issue cites rests on an act that changed. For any but 'entered', pass an empty 'status'."
  2. Changed1 schema field changed
    • changedInput schema / properties / agentActions / description
      Previous value: -"For a duty: what the agent may do beyond commenting, comma-separated — describe, subtasks, ask, wiki, report, support."New value: +"For a duty: what the agent may do beyond commenting, comma-separated — describe, subtasks, ask, wiki, report, support, jira."
  3. Changed1 schema field changed
    • changedInput schema / properties / trigger / description
      Previous value: -"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment. For any but 'entered', pass an empty 'status'."New value: +"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment, or 'actChanged' / 'actTouched' when a legal act the issue cites changed. For any but 'entered', pass an empty 'status'."
  4. Changed2 schema fields changed
    • addedInput schema / properties / environment
      Added value: +{
      +  "default": null,
      +  "description": "For 'deployed': only a deployment to this environment of the project, by name, e.g. 'staging'. Leave out for any.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / trigger / description
      Previous value: -"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed'. For any but 'entered', pass an empty 'status'."New value: +"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed', or 'deployed' when a pipeline reports a deployment. For any but 'entered', pass an empty 'status'."
  5. Changed2 schema fields changed
    • addedInput schema / properties / branch
      Added value: +{
      +  "default": null,
      +  "description": "For 'mrOpened', 'mrMerged' and 'mrClosed': only a merge request going into this branch, e.g. 'main'. Leave out for any.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / trigger / description
      Previous value: -"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone' or 'subtaskStarted'. For any but 'entered', pass an empty 'status'."New value: +"WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone', 'subtaskStarted', or from the repository's webhook 'branchCreated', 'mrOpened', 'mrMerged', 'mrClosed'. For any but 'entered', pass an empty 'status'."
  6. Changed4 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"'checklist' (the default) or 'agent' for a duty. Fixed once the rule exists."New value: +"'checklist' (the default), 'move' to move the issue to 'moveToStatus', or 'agent' for a duty. Fixed once the rule exists."
    • addedInput schema / properties / fromStatus
      Added value: +{
      +  "default": null,
      +  "description": "Only an issue coming from this state, by name. Leave out for any.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / moveToStatus
      Added value: +{
      +  "default": null,
      +  "description": "For action 'move': the state the issue is moved to, by name — finished ones included.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / trigger
      Added value: +{
      +  "default": null,
      +  "description": "WHEN the rule fires: 'entered' (the default), 'versionReleased', 'subtasksDone' or 'subtaskStarted'. For any but 'entered', pass an empty 'status'.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Discloses duplicate suppression via the hidden pm-rule marker, tooLong and tooDeep failure behavior, moveRefused journal outcomes, ownership semantics for webhook and duty rules, spending caps, and permission constraints. This goes far beyond what the annotations provide.

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 core behavior is front-loaded, but the bulk is a single dense paragraph covering every rare trigger and edge case. The length is defensible for an 18-parameter tool with many modes, yet grouping or line breaks would make it substantially easier to scan.

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?

Covers all action modes, trigger edge cases, failure outcomes, ownership rules, permissions, and expected name lookup via list_project_rules. Although there is no output schema, the description explains the important side effects and journal outcomes an agent needs to understand.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema has 100% description coverage, the prose adds important cross-parameter meaning: non-entered triggers require an empty status, move ignores template, a duty's template is an instruction rather than appended text, and fromStatus means different states depending on trigger type.

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?

Opens with a precise verb-resource-effect: 'Add a rule to a project: when an issue enters status, append template to its description.' It then distinguishes the three action modes (checklist, move, agent duty) and signals that action is fixed after creation, which separates it from update_project_rule.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the permission requirement ('Project lead or admin only'), when to pass an empty status or template, how trigger values map to situations, and that list_project_rules lists valid state and type names. It effectively guides the agent through choosing among many trigger/action combinations.

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