@jam-mcp/server 1.0.1 → 1.2.0

package/dist/policy/create-policy.js

@@ -0,0 +1,182 @@
+import { JamError } from "../domain/errors.js";
+import { CREATABLE_FIELDS, } from "../domain/write.js";
+/**
+ * What JAM will agree to create, decided from what Jira says it accepts.
+ *
+ * Creation is the one write with no issue to look at first, so every check
+ * here is against the project's create schema instead. The rule throughout is
+ * the one the rest of the write plane follows: resolve against what Jira just
+ * reported, never against what the caller asserted or what a name suggests. An
+ * issue type id is not derived from a type name, a priority is not sent
+ * because it looked plausible, and a required field JAM cannot express is
+ * refused here rather than posted and rejected as a 400.
+ */
+/**
+ * Jira field ids for the fields JAM can put on a create.
+ *
+ * The bridge between the public contract (CREATABLE_FIELDS, which an agent
+ * sees) and Jira's own ids (which the required-field gate compares against).
+ * Both directions matter: one decides what may be asked for, the other decides
+ * what counts as "JAM supplies this".
+ */
+export const CREATE_FIELD_IDS = {
+    issueType: "issuetype",
+    summary: "summary",
+    description: "description",
+    priority: "priority",
+    labels: "labels",
+    components: "components",
+};
+/** Always sent by JAM, so a project requiring them is still servable. */
+const ALWAYS_SUPPLIED = [CREATE_FIELD_IDS.issueType, CREATE_FIELD_IDS.summary, "project"];
+/**
+ * Fields JAM can supply when asked, and so can satisfy a required flag - but
+ * only if the caller actually asked for them. Required-and-absent is refused.
+ */
+const SUPPLIABLE_ON_REQUEST = {
+    [CREATE_FIELD_IDS.description]: "description",
+    [CREATE_FIELD_IDS.priority]: "priority",
+    [CREATE_FIELD_IDS.labels]: "labels",
+    [CREATE_FIELD_IDS.components]: "components",
+};
+/**
+ * Match a requested issue type against the ones Jira offers for this project.
+ *
+ * Case-insensitive, because "task" and "Task" are the same intent and an agent
+ * has no way to learn Jira's casing before asking. Nothing else is inferred:
+ * the id comes from Jira's own list, and a type that is not on it is refused
+ * with the list attached, so the next move is to pick one rather than to
+ * rephrase the same one.
+ *
+ * Subtask types are refused separately. They need a parent, which is not in
+ * this version's contract, so "not available" would be the wrong answer - the
+ * type exists, and JAM cannot use it yet.
+ */
+export function resolveIssueType(requested, available) {
+    const wanted = requested.trim().toLowerCase();
+    const match = available.find((t) => t.name.toLowerCase() === wanted);
+    if (!match) {
+        const creatable = available.filter((t) => !t.subtask).map((t) => t.name);
+        throw new JamError("JAM_WRITE_ISSUE_TYPE_NOT_AVAILABLE", creatable.length === 0
+            ? `Jira offers no issue types this account can create in this project, so "${requested}" cannot be created.`
+            : `"${requested}" is not an issue type this account can create in this project. Available: ${creatable.join(", ")}.`, {
+            requested,
+            available: available.map((t) => ({ id: t.id, name: t.name, subtask: t.subtask })),
+        });
+    }
+    if (match.subtask) {
+        throw new JamError("JAM_WRITE_ISSUE_TYPE_NOT_AVAILABLE", `"${match.name}" is a subtask type, which needs a parent issue. JAM does not set a parent, so it cannot create one.`, { requested, issueType: match.name, reason: "SUBTASK_UNSUPPORTED" });
+    }
+    return match;
+}
+/**
+ * Refuse a create whose project requires something JAM cannot put on it.
+ *
+ * The alternative - post it and let Jira answer 400 - is worse twice over: the
+ * agent gets a vendor error instead of a JAM decision, and creation is the one
+ * write where "did it happen?" is expensive to answer after the fact. So the
+ * answer is worked out before anything is sent.
+ *
+ * A field Jira says it will default is not JAM's to supply. That is Jira
+ * stating a fact about its own configuration, not JAM guessing one.
+ *
+ * Returns the required field ids, which the plan records so apply can tell a
+ * newly-required field from one that was always there.
+ */
+export function assertRequiredFieldsSupported(fields, input) {
+    const required = fields.filter((f) => f.required);
+    const unsupported = [];
+    for (const field of required) {
+        if (ALWAYS_SUPPLIED.includes(field.id))
+            continue;
+        if (field.hasDefaultValue)
+            continue;
+        const inputKey = SUPPLIABLE_ON_REQUEST[field.id];
+        if (!inputKey) {
+            unsupported.push({ id: field.id, name: field.name, reason: "NOT_IN_JAM_CREATE_CONTRACT" });
+            continue;
+        }
+        if (input[inputKey] === undefined) {
+            unsupported.push({ id: field.id, name: field.name, reason: "REQUIRED_BUT_NOT_PROVIDED" });
+        }
+    }
+    if (unsupported.length > 0) {
+        const named = unsupported.map((f) => `${f.name} (${f.id})`).join(", ");
+        const it = unsupported.length === 1 ? "it" : "them";
+        throw new JamError("JAM_WRITE_REQUIRED_FIELD_UNSUPPORTED", `This project requires ${named} when creating this issue type, and JAM cannot supply ${it}. Create this issue in Jira instead - JAM will not send a create it already knows Jira will reject.`, { unsupported, supported: [...CREATABLE_FIELDS] });
+    }
+    return required.map((f) => f.id);
+}
+/**
+ * Turn a requested value into one Jira currently offers for that field.
+ *
+ * An unconstrained field passes the value through: there is no list to check
+ * it against, and inventing one would refuse valid input. Absent and empty are
+ * different - absent means Jira did not constrain the field, empty means it
+ * constrains it and offers nothing.
+ *
+ * The shape is resolveTransition's, deliberately: human intent, then
+ * Jira-provided candidates, then a concrete Jira value. Nothing in between
+ * guesses.
+ */
+export function resolveAllowedValue(field, requested, label) {
+    if (!field?.allowedValues)
+        return { requested, resolved: requested };
+    const wanted = requested.trim().toLowerCase();
+    const match = field.allowedValues.find((v) => v.name?.toLowerCase() === wanted);
+    if (!match?.name) {
+        const allowed = field.allowedValues.map((v) => v.name).filter(Boolean);
+        throw new JamError("JAM_WRITE_VALUE_NOT_ALLOWED", allowed.length === 0
+            ? `Jira offers no ${label} values for this project and issue type, so "${requested}" cannot be set.`
+            : `"${requested}" is not an allowed ${label} for this project and issue type. Allowed: ${allowed.join(", ")}.`, { field: field.id, requested, allowed });
+    }
+    return { requested, resolved: match.name };
+}
+/**
+ * Are this plan's premises still true?
+ *
+ * Semantic, not a document comparison. Comparing a hash of the metadata would
+ * make an unrelated optional field appearing on the create screen invalidate
+ * every outstanding plan - which is wrong, and on an active project constant.
+ * What matters is narrower: the issue type still exists, no new required field
+ * has appeared that JAM cannot fill, and every value resolved from an allowed
+ * list is still on it.
+ *
+ * Everything else about the schema may change freely between plan and apply.
+ */
+export function assertSchemaUnchanged(requirements, issueTypes, fields, input) {
+    const stillOffered = issueTypes.find((t) => t.id === requirements.issueTypeId);
+    if (!stillOffered) {
+        throw schemaChanged(`Issue type ${requirements.issueTypeName} is no longer available to this account in this project.`, { issueTypeId: requirements.issueTypeId, issueType: requirements.issueTypeName });
+    }
+    // A required field JAM cannot fill is a refusal whether it was there at plan
+    // time or arrived since - but arriving since is a changed schema rather than
+    // a bad request, so it is reported as one.
+    try {
+        assertRequiredFieldsSupported(fields, input);
+    }
+    catch (err) {
+        if (err instanceof JamError && err.code === "JAM_WRITE_REQUIRED_FIELD_UNSUPPORTED") {
+            throw schemaChanged("The create screen for this issue type now requires a field JAM cannot supply.", { cause: err.details });
+        }
+        throw err;
+    }
+    const byId = new Map(fields.map((f) => [f.id, f]));
+    for (const resolved of requirements.resolvedValues) {
+        const allowed = byId.get(resolved.fieldId)?.allowedValues;
+        // A field that stopped being constrained is not a problem: the value JAM
+        // resolved is still a value, and Jira is no longer restricting it.
+        if (!allowed)
+            continue;
+        if (!allowed.some((v) => v.name === resolved.resolved)) {
+            throw schemaChanged(`"${resolved.resolved}" is no longer an allowed value for ${resolved.fieldId} in this project.`, {
+                field: resolved.fieldId,
+                planned: resolved.resolved,
+                allowed: allowed.map((v) => v.name).filter(Boolean),
+            });
+        }
+    }
+}
+function schemaChanged(what, details) {
+    return new JamError("JAM_WRITE_SCHEMA_CHANGED", `${what} This plan was built on the create schema as it was, so it no longer describes a create JAM can make. Nothing was created - plan again against the current schema.`, details);
+}

package/dist/policy/write-policy.d.ts

@@ -0,0 +1,69 @@
+import { type ExistingIssueOperation, type FieldUpdateInput, type JiraTransition, type WriteOperation } from "../domain/write.js";
+/**
+ * What a write is allowed to be, decided before anything reaches Jira.
+ *
+ * These checks exist so a refusal is a JAM answer rather than a Jira 403 or a
+ * 404 with no explanation. "You asked to change an issue in another project"
+ * and "Jira says that issue does not exist" look identical from the REST layer
+ * and mean entirely different things to whoever has to act next.
+ */
+/**
+ * How long a plan stays applicable.
+ *
+ * Short on purpose. A plan carries a snapshot of the issue, and the older that
+ * snapshot is the more likely apply is about to reject it anyway - so the
+ * window is measured in the time an agent needs to decide, not in how long a
+ * person might leave a terminal open.
+ */
+export declare const PLAN_TTL_MS: number;
+/**
+ * Which project an issue key belongs to.
+ *
+ * Parsed rather than looked up: a malformed key should be refused before it is
+ * spent on a Jira round trip.
+ */
+export declare function projectKeyOf(issueKey: string): string | undefined;
+/**
+ * Writes stay inside the project this workspace is bound to.
+ *
+ * The binding is what the user consented to when they set JAM up. An agent
+ * holding a key from somewhere else - copied from a link, inferred from a
+ * comment - must not be able to reach into another team's project through it.
+ */
+export declare function assertWriteScope(issueKey: string, configuredProject: string): string;
+export declare function assertOperationAllowed(operation: string): WriteOperation;
+/**
+ * Narrow an already-allowed operation to one that acts on an existing issue.
+ *
+ * Reached only after routing has sent `issue.create` elsewhere, so this is a
+ * type-level guarantee rather than a second policy decision - but it is a
+ * guarantee worth having, because everything downstream reads an issue key
+ * that creation does not have.
+ */
+export declare function assertExistingIssueOperation(operation: string): ExistingIssueOperation;
+/**
+ * Reject anything outside the field whitelist before planning goes further.
+ *
+ * Returns the requested fields in whitelist order so a plan's `before` and
+ * `intendedAfter` are comparable regardless of how the caller ordered them.
+ */
+export declare function assertFieldsAllowed(input: FieldUpdateInput): FieldUpdateInput;
+/**
+ * Match a requested status against what Jira currently offers.
+ *
+ * Jira's transition ids are per-workflow and not derivable from a status name,
+ * so this only ever selects from transitions Jira just reported. When nothing
+ * matches, the available names go back with the error - the agent's next move
+ * is to pick one of them, not to try harder at the same one.
+ */
+export declare function resolveTransition(target: string, available: JiraTransition[]): JiraTransition;
+export declare function planExpired(expiresAt: string, now: Date): boolean;
+/**
+ * Has the issue moved since the plan was made?
+ *
+ * Jira's `updated` timestamp is the revision marker: it changes on any edit,
+ * including ones JAM did not make and cannot see the shape of. Comparing it is
+ * what stops an agent applying a decision it made against an issue that no
+ * longer exists in that form.
+ */
+export declare function assertUnchanged(issueKey: string, baseUpdated: string, currentUpdated: string): void;

package/dist/policy/write-policy.js

@@ -0,0 +1,128 @@
+import { JamError } from "../domain/errors.js";
+import { EXISTING_ISSUE_OPERATIONS, isExistingIssueOperation, isWritableField, isWriteOperation, WRITABLE_FIELDS, WRITE_OPERATIONS, } from "../domain/write.js";
+/**
+ * What a write is allowed to be, decided before anything reaches Jira.
+ *
+ * These checks exist so a refusal is a JAM answer rather than a Jira 403 or a
+ * 404 with no explanation. "You asked to change an issue in another project"
+ * and "Jira says that issue does not exist" look identical from the REST layer
+ * and mean entirely different things to whoever has to act next.
+ */
+/**
+ * How long a plan stays applicable.
+ *
+ * Short on purpose. A plan carries a snapshot of the issue, and the older that
+ * snapshot is the more likely apply is about to reject it anyway - so the
+ * window is measured in the time an agent needs to decide, not in how long a
+ * person might leave a terminal open.
+ */
+export const PLAN_TTL_MS = 10 * 60 * 1000;
+const KEY_PATTERN = /^([A-Z][A-Z0-9_]*)-(\d+)$/;
+/**
+ * Which project an issue key belongs to.
+ *
+ * Parsed rather than looked up: a malformed key should be refused before it is
+ * spent on a Jira round trip.
+ */
+export function projectKeyOf(issueKey) {
+    return KEY_PATTERN.exec(issueKey.trim().toUpperCase())?.[1];
+}
+/**
+ * Writes stay inside the project this workspace is bound to.
+ *
+ * The binding is what the user consented to when they set JAM up. An agent
+ * holding a key from somewhere else - copied from a link, inferred from a
+ * comment - must not be able to reach into another team's project through it.
+ */
+export function assertWriteScope(issueKey, configuredProject) {
+    const project = projectKeyOf(issueKey);
+    if (!project) {
+        throw new JamError("JAM_WRITE_SCOPE_VIOLATION", `"${issueKey}" is not a Jira issue key.`, { issueKey });
+    }
+    const configured = configuredProject.trim().toUpperCase();
+    if (!configured) {
+        throw new JamError("JAM_SETUP_REQUIRED", "No Jira project is configured for this workspace, so JAM cannot tell whether this write is in scope.", { issueKey });
+    }
+    if (project !== configured) {
+        throw new JamError("JAM_WRITE_SCOPE_VIOLATION", `${issueKey} belongs to project ${project}, but this workspace is bound to ${configured}. JAM writes only within the configured project.`, { issueKey, project, configuredProject: configured });
+    }
+    return project;
+}
+export function assertOperationAllowed(operation) {
+    if (!isWriteOperation(operation)) {
+        throw new JamError("JAM_WRITE_OPERATION_NOT_ALLOWED", `"${operation}" is not a JAM write operation. Supported: ${WRITE_OPERATIONS.join(", ")}.`, { operation, supported: [...WRITE_OPERATIONS] });
+    }
+    return operation;
+}
+/**
+ * Narrow an already-allowed operation to one that acts on an existing issue.
+ *
+ * Reached only after routing has sent `issue.create` elsewhere, so this is a
+ * type-level guarantee rather than a second policy decision - but it is a
+ * guarantee worth having, because everything downstream reads an issue key
+ * that creation does not have.
+ */
+export function assertExistingIssueOperation(operation) {
+    if (!isExistingIssueOperation(operation)) {
+        throw new JamError("JAM_WRITE_OPERATION_NOT_ALLOWED", `"${operation}" does not change an existing issue. Operations that do: ${EXISTING_ISSUE_OPERATIONS.join(", ")}.`, { operation, supported: [...EXISTING_ISSUE_OPERATIONS] });
+    }
+    return operation;
+}
+/**
+ * Reject anything outside the field whitelist before planning goes further.
+ *
+ * Returns the requested fields in whitelist order so a plan's `before` and
+ * `intendedAfter` are comparable regardless of how the caller ordered them.
+ */
+export function assertFieldsAllowed(input) {
+    const requested = Object.keys(input).filter((key) => input[key] !== undefined);
+    if (requested.length === 0) {
+        throw new JamError("JAM_WRITE_FIELD_NOT_ALLOWED", `field.update needs at least one field. Supported: ${WRITABLE_FIELDS.join(", ")}.`, { supported: [...WRITABLE_FIELDS] });
+    }
+    const rejected = requested.filter((key) => !isWritableField(key));
+    if (rejected.length > 0) {
+        throw new JamError("JAM_WRITE_FIELD_NOT_ALLOWED", `JAM cannot write ${rejected.join(", ")}. Supported: ${WRITABLE_FIELDS.join(", ")}.`, { rejected, supported: [...WRITABLE_FIELDS] });
+    }
+    const ordered = {};
+    for (const field of WRITABLE_FIELDS) {
+        const value = input[field];
+        if (value !== undefined)
+            Object.assign(ordered, { [field]: value });
+    }
+    return ordered;
+}
+/**
+ * Match a requested status against what Jira currently offers.
+ *
+ * Jira's transition ids are per-workflow and not derivable from a status name,
+ * so this only ever selects from transitions Jira just reported. When nothing
+ * matches, the available names go back with the error - the agent's next move
+ * is to pick one of them, not to try harder at the same one.
+ */
+export function resolveTransition(target, available) {
+    const wanted = target.trim().toLowerCase();
+    const match = available.find((t) => t.to.toLowerCase() === wanted) ??
+        available.find((t) => t.name.toLowerCase() === wanted);
+    if (!match) {
+        throw new JamError("JAM_WRITE_TRANSITION_NOT_AVAILABLE", available.length === 0
+            ? `Jira offers no transitions from this issue's current status for this account, so it cannot be moved to "${target}".`
+            : `"${target}" is not reachable from this issue's current status. Available: ${available.map((t) => t.to).join(", ")}.`, { target, available: available.map((t) => ({ id: t.id, name: t.name, to: t.to })) });
+    }
+    return match;
+}
+export function planExpired(expiresAt, now) {
+    return now.getTime() >= Date.parse(expiresAt);
+}
+/**
+ * Has the issue moved since the plan was made?
+ *
+ * Jira's `updated` timestamp is the revision marker: it changes on any edit,
+ * including ones JAM did not make and cannot see the shape of. Comparing it is
+ * what stops an agent applying a decision it made against an issue that no
+ * longer exists in that form.
+ */
+export function assertUnchanged(issueKey, baseUpdated, currentUpdated) {
+    if (baseUpdated === currentUpdated)
+        return;
+    throw new JamError("JAM_WRITE_CONFLICT", `${issueKey} changed after this plan was made, so the plan no longer describes the issue. Re-plan against the current state.`, { issueKey, planUpdated: baseUpdated, currentUpdated });
+}

package/dist/ports/jira-create-metadata.port.d.ts

@@ -0,0 +1,25 @@
+import type { CreateFieldMetadata, CreateIssueType } from "../domain/write.js";
+/**
+ * What Jira will accept when creating an issue in one project, right now.
+ *
+ * Separate from `JiraWritePort` on purpose. Everything behind that port
+ * changes something; nothing behind this one does. Folding schema discovery
+ * into the write port would put a read on the far side of a boundary whose
+ * whole documented rule is "these calls mutate, and none of them retry" - and
+ * the rule is worth more than the one fewer interface.
+ *
+ * Kept out of `JiraReadPort` too, for the opposite reason: that port answers
+ * questions about issues, with completeness semantics attached to every
+ * result. This answers a question about a project's configuration, and
+ * `meta.complete` would mean nothing here.
+ *
+ * These calls do not retry. Their answers decide a mutation, and a retried
+ * answer is a possibly-stale one - the same argument that keeps
+ * `getTransitions` on the non-retrying side.
+ */
+export interface JiraCreateMetadataPort {
+    /** Issue types this account may create in this project. */
+    getIssueTypes(projectKey: string): Promise<CreateIssueType[]>;
+    /** The create screen's fields for one issue type in one project. */
+    getCreateFields(projectKey: string, issueTypeId: string): Promise<CreateFieldMetadata[]>;
+}

package/dist/ports/jira-create-metadata.port.js

@@ -0,0 +1 @@
+export {};

package/dist/ports/jira-read.port.d.ts

@@ -20,6 +20,15 @@ export type GetIssuesRequest = {
     keys: string[];
     fields: string[];
 };
+export type GetIssueRequest = {
+    key: string;
+    fields: string[];
+};
+export type GetIssueResult = {
+    /** Absent when Jira has no such issue, or this account cannot see it. */
+    issue?: FullIssueContext;
+    responseBytes: number;
+};
 export type GetIssuesResult = {
     issues: FullIssueContext[];
     /** Keys that were requested but not returned (missing or not permitted). */
@@ -59,6 +68,20 @@ export type ListProjectsResult = {
 };
 export interface JiraReadPort {
     searchPage(req: SearchPageRequest): Promise<SearchPageResult>;
+    /**
+     * One issue, read directly by key.
+     *
+     * Separate from `getIssues` because ConsistencyPolicy requires a direct
+     * issue GET for anything that decides or confirms a write, and `getIssues`
+     * is not one: it is a bulk endpoint that takes a list, and a bulk read is
+     * free to answer from a different path than a single-issue GET. The
+     * distinction only matters in one place - the write plane - which is exactly
+     * where being wrong about it is most expensive.
+     *
+     * Reads and writes both use it: the pre-write conflict check, the post-write
+     * confirmation, and the post-create confirmation.
+     */
+    getIssue(req: GetIssueRequest): Promise<GetIssueResult>;
     getIssues(req: GetIssuesRequest): Promise<GetIssuesResult>;
     getComments(req: GetCommentsRequest): Promise<GetCommentsResult>;
     /** Used by `jam doctor` to prove authentication works. */

package/dist/ports/jira-write.port.d.ts

@@ -1,12 +1,35 @@
+import type { JiraTransition } from "../domain/write.js";
 /**
- * Write path is out of scope for the first release - the structural boundary
- * exists so adding writes later does not reshape the application layer.
- * See ConsistencyPolicy: a write must be confirmed with a direct issue GET,
- * never with a JQL search result.
+ * The mutating half of Jira, kept apart from reading on purpose.
+ *
+ * Two rules govern everything behind this port:
+ *
+ *  - A write is not confirmed by its own HTTP response. ConsistencyPolicy
+ *    requires a direct issue GET afterwards, which is the read port's job -
+ *    this port never reads back its own work.
+ *  - Nothing here retries. A read that times out can be repeated; a POST that
+ *    times out may already have been applied, and repeating it is how one
+ *    comment becomes two. Ambiguity is resolved by looking, not by trying
+ *    again.
+ *
+ * The field map is generic at this layer because Jira's is. The public MCP
+ * surface is not: only whitelisted operations reach it (see domain/write.ts).
  */
 export interface JiraWritePort {
+    /**
+     * Create one issue. The only call here that brings an issue into existence,
+     * and the one where a retry is most expensive: a duplicate update is a
+     * no-op, a duplicate create is a second issue on someone's board.
+     */
+    createIssue(fields: Record<string, unknown>): Promise<{
+        id: string;
+        key: string;
+    }>;
     updateIssue(key: string, fields: Record<string, unknown>): Promise<void>;
     addComment(key: string, body: string): Promise<{
         id: string;
     }>;
+    /** Transitions Jira offers for this issue right now, for this account. */
+    getTransitions(key: string): Promise<JiraTransition[]>;
+    transitionIssue(key: string, transitionId: string): Promise<void>;
 }

package/package.json

@@ -1,69 +1,69 @@
-{
-  "name": "@jam-mcp/server",
-  "version": "1.0.1",
-  "description": "JAM (Jira Agent MCP) - agent-facing Jira access layer: MCP server, setup core, and CLI",
-  "keywords": [
-    "jira",
-    "mcp",
-    "model-context-protocol",
-    "claude-code",
-    "codex",
-    "jira-api"
-  ],
-  "homepage": "https://github.com/colosair/jam#readme",
-  "bugs": {
-    "url": "https://github.com/colosair/jam/issues"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/colosair/jam.git",
-    "directory": "packages/server"
-  },
-  "author": "colosair (https://github.com/colosair)",
-  "type": "module",
-  "bin": {
-    "jam-server": "dist/index.js"
-  },
-  "main": "dist/index.js",
-  "types": "dist/index.d.ts",
-  "engines": {
-    "node": ">=20"
-  },
-  "files": [
-    "dist",
-    "!dist/**/*.js.map",
-    "README.md"
-  ],
-  "scripts": {
-    "build": "tsc",
-    "dev": "tsc --watch",
-    "test": "vitest run",
-    "test:watch": "vitest"
-  },
-  "dependencies": {
-    "@jam-mcp/launcher": "1.0.1",
-    "@modelcontextprotocol/sdk": "^1.30.0",
-    "yaml": "^2.9.0",
-    "zod": "^4.4.3"
-  },
-  "devDependencies": {
-    "@types/node": "^24.0.0",
-    "typescript": "^5.9.0",
-    "vitest": "^4.1.11"
-  },
-  "license": "MIT",
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
-    },
-    "./cli-entry": {
-      "types": "./dist/cli-entry.d.ts",
-      "default": "./dist/cli-entry.js"
-    }
-  },
-  "publishConfig": {
-    "access": "public",
-    "registry": "https://registry.npmjs.org/"
-  }
-}
+{
+  "name": "@jam-mcp/server",
+  "version": "1.2.0",
+  "description": "JAM (Jira Agent MCP) - agent-facing Jira access layer: MCP server, setup core, and CLI",
+  "keywords": [
+    "jira",
+    "mcp",
+    "model-context-protocol",
+    "claude-code",
+    "codex",
+    "jira-api"
+  ],
+  "homepage": "https://github.com/colosair/jam#readme",
+  "bugs": {
+    "url": "https://github.com/colosair/jam/issues"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/colosair/jam.git",
+    "directory": "packages/server"
+  },
+  "author": "colosair (https://github.com/colosair)",
+  "type": "module",
+  "bin": {
+    "jam-server": "dist/index.js"
+  },
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "engines": {
+    "node": ">=20"
+  },
+  "files": [
+    "dist",
+    "!dist/**/*.js.map",
+    "README.md"
+  ],
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsc --watch",
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
+  "dependencies": {
+    "@jam-mcp/launcher": "1.2.0",
+    "@modelcontextprotocol/sdk": "^1.30.0",
+    "yaml": "^2.9.0",
+    "zod": "^4.4.3"
+  },
+  "devDependencies": {
+    "@types/node": "^24.0.0",
+    "typescript": "^5.9.0",
+    "vitest": "^4.1.11"
+  },
+  "license": "MIT",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./cli-entry": {
+      "types": "./dist/cli-entry.d.ts",
+      "default": "./dist/cli-entry.js"
+    }
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/"
+  }
+}