tdoms-mcp 0.6.2 → 0.8.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -66,6 +66,39 @@ tool_timeout_sec = 60
66
66
 
67
67
  Restart or reload the agent's MCP servers after changing the configuration.
68
68
 
69
+ ## Agent Skill
70
+
71
+ The package includes a portable developer skill at `skills/tdoms-mcp-routing`. Its `SKILL.md` teaches agents how to select core, full-profile, or Octo tools; discover site-specific values; perform guarded task, source, compile, checkout, promote, transfer, branch, and approval workflows; and verify final TD/OMS state.
72
+
73
+ The CLI and local UI can install the complete skill folder for detected IBM Bob, Codex, Claude Code, VS Code Copilot, Kiro, and Gemini CLI installations. The skill contains no credentials, connection profiles, organization-specific values, or personal information. Runtime tool schemas and values returned by the connected TD/OMS server remain authoritative.
74
+
75
+ List the native skill targets and their installation status:
76
+
77
+ ```shell
78
+ tdoms-mcp skills
79
+ ```
80
+
81
+ Install or update the skill for one agent. User scope makes it available across that agent's projects; workspace scope installs it only in the current project:
82
+
83
+ ```shell
84
+ tdoms-mcp install-skill ibm-bob --scope user --confirm
85
+ tdoms-mcp install-skill codex --scope user --confirm
86
+ tdoms-mcp install-skill claude-code --scope workspace --confirm
87
+ tdoms-mcp install-skill vscode --scope workspace --confirm
88
+ tdoms-mcp install-skill kiro --scope user --confirm
89
+ tdoms-mcp install-skill gemini-cli --scope user --confirm
90
+ ```
91
+
92
+ Install or update the skill for every detected compatible agent:
93
+
94
+ ```shell
95
+ tdoms-mcp install-detected-skills --scope user --confirm
96
+ ```
97
+
98
+ The Agent Setup page in `tdoms-mcp ui` provides the same actions with User skill and Workspace skill scope controls. Existing skill folders are timestamped and backed up before replacement, concurrent installs are locked, and a failed replacement restores the prior folder. Bob users must enable Advanced mode; existing agent sessions may need to be restarted or reloaded after installation. Claude Desktop chat requires a ZIP upload to **Customize > Skills**; its row provides a correctly packaged download instead of reporting a local folder copy as installed.
99
+
100
+ The **Codex** row covers the Codex desktop app, CLI, and VS Code extension through `~/.agents/skills`. Restart Codex or reload the VS Code window and start a new task if a newly installed skill is not visible. The **Visual Studio Code** skill action installs for every compatible extension it detects: Codex through `~/.agents/skills`, Claude Code through `~/.claude/skills`, and GitHub Copilot through `~/.copilot/skills`. Use `/skills` in agents that expose that menu, or invoke the skill by name in Codex and Claude Code.
101
+
69
102
  Detect supported local clients from the installed command:
70
103
 
71
104
  ```shell
@@ -95,6 +128,8 @@ Detection and installation are environment-local. Running the installer on Windo
95
128
 
96
129
  Client installation never copies TD/OMS passwords or tokens into agent configuration. It registers only the local stdio command and the `core` tool profile. Existing files are backed up, writes are atomic, invalid JSON is rejected, and failed client updates are restored.
97
130
 
131
+ MCP and skill installation are separate on purpose: the MCP provides live TD/OMS tools, while the skill teaches an agent how to route requests and perform guarded change-management workflows. Install both for the complete experience.
132
+
98
133
  ## Core Workflow
99
134
 
100
135
  The default profile exposes seven tools:
@@ -132,8 +167,13 @@ All tools that can change TD/OMS require explicit confirmation. `tdoms_call_api`
132
167
  ```text
133
168
  tdoms-mcp ui Open the local connection and agent setup UI
134
169
  tdoms-mcp clients List detected MCP-capable agents
170
+ tdoms-mcp skills List native skill targets and status
135
171
  tdoms-mcp install-client <id> --confirm Configure one detected agent
136
172
  tdoms-mcp install-detected --confirm Configure all detected agents
173
+ tdoms-mcp install-skill <id> --scope user --confirm
174
+ Install a skill for one detected agent
175
+ tdoms-mcp install-detected-skills --scope user --confirm
176
+ Install skills for all compatible agents
137
177
  tdoms-mcp mcp Start the core stdio MCP server
138
178
  tdoms-mcp mcp --profile full Start the complete tool profile
139
179
  tdoms-mcp smoke Check local configuration without connecting
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "tdoms-mcp",
3
- "version": "0.6.2",
3
+ "version": "0.8.3",
4
4
  "description": "Agent-neutral MCP server for TD/OMS change-management workflows.",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -37,6 +37,8 @@
37
37
  "secure-storage": "node src/index.js secure-storage",
38
38
  "clients": "node src/index.js clients",
39
39
  "clients:install": "node src/index.js install-detected --confirm",
40
+ "skills": "node src/index.js skills",
41
+ "skills:install": "node src/index.js install-detected-skills --scope user --confirm",
40
42
  "test": "node --test"
41
43
  },
42
44
  "dependencies": {
@@ -44,6 +46,7 @@
44
46
  "express": "^4.19.2",
45
47
  "jsonc-parser": "^3.3.1",
46
48
  "lucide-static": "^1.24.0",
49
+ "yazl": "^3.3.1",
47
50
  "zod": "^4.1.12"
48
51
  },
49
52
  "engines": {
@@ -1,48 +1,89 @@
1
1
  ---
2
2
  name: tdoms-mcp-routing
3
- description: Use TD/OMS change management through the standalone TD/OMS MCP or Octo MCP tools. Trigger for tasks, requests, source, objects, checkout, promote, transfer, compile, branches, connection lists, logs, spool files, conflicts, labels, and other TD/OMS workflows, especially when an agent incorrectly asks for Octo sign-in or a programmer ID.
3
+ description: Operate TD/OMS change management through the standalone TD/OMS MCP or, when necessary, the Octo extension MCP. Use for developer workflows involving tasks, requests, objects, source, checkout, promote, transfer, compile, branches, solutions, connection lists, logs, spool files, revisions, conflicts, ratification, labels, trackers, remote jobs, or TD/OMS option discovery. Also use when choosing between standalone and Octo tools, diagnosing Octo sign-in or programmer-context failures, or explaining TD/OMS MCP capabilities and limits.
4
4
  ---
5
5
 
6
6
  # TD/OMS MCP Routing
7
7
 
8
- Prefer the standalone TD/OMS MCP when available. It works independently of the Octo VS Code UI.
8
+ Use the standalone MCP as the primary automation surface. It talks to the configured TD/OMS REST server and does not control VS Code or require an Octo session.
9
9
 
10
- ## Standalone Core Flow
10
+ ## Load References Deliberately
11
11
 
12
- 1. Call `tdoms_get_current_context`. Let it select the only connection and derive the TD/OMS programmer ID from the saved profile.
13
- 2. Call `tdoms_list_capabilities` when the requested workflow or required choices are unclear.
14
- 3. Call `tdoms_discover_options` before choosing application, environment, programmer, path, reason, target, object, template, conflict resolution, or any site-specific value.
15
- 4. Use `tdoms_discover_options` for structured task, request, component, source, queue, compile, history, log, spool, tracker, dependency, and dashboard reads.
16
- 5. For changes, call `tdoms_plan_workflow` with the exact context, selections, and `optionSelections` for values returned by discovery. Show the user its action, target, endpoint/body preview, warnings, and blockers.
17
- 6. Call `tdoms_execute_workflow` with the returned `planId` and `confirm: true` only after the user approves that exact preview.
18
- 7. Call `tdoms_get_workflow_status` for asynchronous work.
12
+ - Read [references/workflow-playbooks.md](references/workflow-playbooks.md) before performing a domain workflow such as checkout, promote, source save, compile, completion, ratification, branch work, or conflict handling.
13
+ - Read [references/tool-and-extension-map.md](references/tool-and-extension-map.md) when selecting tools, comparing the standalone MCP with Octo, or checking whether a capability is core-only, full-profile, UI-only, or unsupported.
14
+ - Read [references/tdoms-domain-and-sources.md](references/tdoms-domain-and-sources.md) when terminology, lifecycle semantics, source authority, or version differences matter.
19
15
 
20
- Never guess a value when discovery returns no choices or `supported: false`. Ask one concise question instead.
16
+ ## Establish Runtime Context
21
17
 
22
- For "my tasks," use option set `tasks` without supplying a programmer. The MCP uses the saved TD/OMS username automatically. Set `context.allUsers: true` only when the user requests tasks for everyone.
18
+ 1. Inspect the tools actually available in the current agent session. Runtime tool schemas override this skill if names or inputs differ.
19
+ 2. Call `tdoms_list_connections`.
20
+ 3. If exactly one connection exists, omit `connectionId` where the schema permits and call `tdoms_get_current_context`.
21
+ 4. If several connections exist, select only from the returned profiles. Ask the user to choose when the request does not identify one.
22
+ 5. If no connection exists, direct the user to save and test one through `tdoms-mcp ui`. Never request a password, token, or certificate contents in chat.
23
+ 6. Treat `user.programmerId` from current context as the default identity for "my" records. Do not ask for a programmer ID unless the user is reassigning work, selecting another programmer, or the server cannot derive one.
23
24
 
24
- ## Mutation Rules
25
+ ## Choose the Surface
25
26
 
26
- - Read current state before planning.
27
- - Treat source saves, checkout, promote, transfer, compile, complete, delete, process, queue, release, close, and configuration changes as mutations.
28
- - Never set `confirm: true` without explicit approval of the current plan.
29
- - Stop when TD/OMS reports warnings, locks, conflicts, authority failures, or changed state. Summarize the result and replan if needed.
30
- - Never ask the user to paste TD/OMS credentials into chat.
27
+ - Prefer the seven `core` tools for portable agent workflows and small tool budgets.
28
+ - Use `tdoms_discover_options` for both choices and structured reads that replace Octo views.
29
+ - Use `tdoms_plan_workflow` and `tdoms_execute_workflow` whenever the requested mutation appears in `tdoms_list_capabilities`.
30
+ - Use a `full` named tool when no core capability exists or when a typed tool gives safer inputs, richer diagnostics, or a complete read workflow.
31
+ - Use Octo tools only when the user explicitly needs an Octo panel/editor or when the standalone MCP lacks the required TD/OMS or Octo-cloud operation.
32
+ - Do not use `tdoms_call_api` until named and planned tools have been ruled out and the endpoint and body are documented for the connected TD/OMS version.
31
33
 
32
- ## Full Profile
34
+ ## Read Workflow
33
35
 
34
- When `TDOMS_MCP_PROFILE=full`, prefer a specific named read tool when it is clearer than generic discovery. Named mutation tools still require explicit approval and `confirm: true`.
36
+ 1. Resolve context.
37
+ 2. Call `tdoms_list_capabilities` if the workflow is unclear.
38
+ 3. Call `tdoms_discover_options` with the relevant `optionSet`, narrow context, and pagination.
39
+ 4. Treat returned `value` fields as machine inputs and `label` fields as display text.
40
+ 5. Honor `enabled`, `source.authoritative`, `warnings`, and `supported`.
41
+ 6. Follow pagination rather than assuming the first page is complete.
42
+ 7. Verify the returned application, task, environment, object, library, member, or path before reporting results.
35
43
 
36
- Use typed transfer tools in this sequence: select targets, prepare, inspect warnings, execute, then monitor progress. Use typed source tools to read the latest source and last-change marker before saving. Use compile-and-check to retrieve diagnostics instead of asking the user to paste spool output.
44
+ For "my tasks," discover `tasks` without a programmer filter. The MCP applies the saved TD/OMS username in uppercase. Set `context.allUsers: true` only when the user requests a cross-user search.
37
45
 
38
- ## Octo MCP Fallback
46
+ ## Planned Mutation Workflow
39
47
 
40
- If only the extension MCP is available:
48
+ Follow this sequence for every supported core mutation:
41
49
 
42
- - Use `OMS-Database-REST-API.getRecords` for reads and task lists.
43
- - Use `TD-OMS-Task-API` only for task mutations.
44
- - Use `TD-OMS-Branch-Service-API` for branch mutations.
45
- - Treat `Octo-Views` and `Octo-Wizards` as UI launchers, not proof that an action completed.
46
- - Do not require `Octo-User-Context` before direct TD/OMS reads.
50
+ 1. Read the current state.
51
+ 2. Discover every site-specific choice required by the capability.
52
+ 3. Call `tdoms_plan_workflow` with:
53
+ - the exact capability `workflow` id;
54
+ - stable identifiers in `context`;
55
+ - mutation fields in `selections`;
56
+ - each chosen discovery value in `optionSelections`, keyed by option-set name.
57
+ 4. Stop on blockers. Never invent a missing option or silently replace an unavailable choice.
58
+ 5. Present the plan title, target, endpoint/body preview, warnings, and expiry to the user.
59
+ 6. Obtain explicit approval for that exact preview.
60
+ 7. Call `tdoms_execute_workflow` with the matching `planId` and `confirm: true`.
61
+ 8. Call `tdoms_get_workflow_status` and/or a domain read to verify the postcondition.
47
62
 
48
- If Octo user context says sign-in is required but a direct TD/OMS read succeeds, continue with the direct tool and report that the Octo UI context is stale. Retry programmer filters in uppercase before reporting that no tasks exist.
63
+ Plans expire after ten minutes, execute once, and are rejected if state or selected options change. Re-discover and replan instead of trying to force a stale plan.
64
+
65
+ ## Full-Profile Mutation Workflow
66
+
67
+ Some full-profile actions, including task creation, source save, compile, connection-list processing, and several branch or request actions, are not represented by a core plan id.
68
+
69
+ 1. Read current state and discover choices first.
70
+ 2. Prefer a typed named tool over an `*_action` tool or raw API call.
71
+ 3. Construct the exact arguments but do not call the mutation yet.
72
+ 4. Show the user the action, target, important fields, and likely effect.
73
+ 5. Call the named tool with `confirm: true` only after explicit approval.
74
+ 6. Re-read TD/OMS to verify the result. A successful transport response is not sufficient proof of the final lifecycle state.
75
+
76
+ ## Safety And Failure Rules
77
+
78
+ - Treat create, change, save, connect, disconnect, process, queue, release, checkout, promote, transfer, complete, ratify, resolve, close, schedule, delete, purge, and configuration operations as mutations.
79
+ - Do not equate `OMQRTO/select` with a completed transfer; it discovers eligible targets and may initialize preparatory server state.
80
+ - Stop on authority errors, locks, pre-transfer checks, warnings requiring a decision, version conflicts, stale source markers, compile failures, or changed task state.
81
+ - Preserve server casing and exact codes. Retry a programmer lookup in uppercase only when identity-derived lookup returned no records.
82
+ - Do not broaden to all users, all applications, or unfiltered database queries without a user need.
83
+ - Do not claim that an Octo wizard or view launcher completed work. It only opened UI.
84
+ - If Octo user context reports sign-in required but standalone reads succeed, continue through the standalone MCP and describe the Octo session as separate or stale.
85
+ - Never expose saved connection metadata beyond what the task requires. Never print passwords, JWTs, master keys, CA contents, local credential files, or personal filesystem paths.
86
+
87
+ ## Finish With Evidence
88
+
89
+ Report the identifiers used, the observed final state, warnings that remain, and any follow-up state check needed. Distinguish clearly between planned, submitted, queued, running, completed, rejected, and unsupported work.
@@ -1,4 +1,4 @@
1
- interface:
2
- display_name: "TD/OMS MCP Routing"
3
- short_description: "Route TD/OMS change-management workflows"
4
- default_prompt: "Use $tdoms-mcp-routing to handle this TD/OMS request safely through MCP."
1
+ interface:
2
+ display_name: "TD/OMS Change Management"
3
+ short_description: "Run safe TD/OMS developer workflows"
4
+ default_prompt: "Use $tdoms-mcp-routing to execute this TD/OMS developer workflow with live option discovery, explicit approval, and final-state verification."
@@ -0,0 +1,78 @@
1
+ # TD/OMS Domain And Sources
2
+
3
+ ## Contents
4
+
5
+ - Source authority
6
+ - Domain model
7
+ - Change lifecycle
8
+ - Version and site variability
9
+ - Public references
10
+
11
+ ## Source Authority
12
+
13
+ Use evidence in this order:
14
+
15
+ 1. Live MCP tool names, schemas, and responses.
16
+ 2. Choices returned by the connected TD/OMS server.
17
+ 3. The standalone MCP capability registry and typed tool implementation for the installed package version.
18
+ 4. Documentation supplied by the user's TD/OMS administrators for that server version and site policy.
19
+ 5. Official public Remain Software product, marketplace, and release documentation for conceptual context.
20
+ 6. This skill's audited extension comparison as a versioned compatibility snapshot.
21
+
22
+ Do not derive REST payloads, reason codes, environment codes, or authorization decisions from marketing pages. Public documentation establishes concepts; live schemas and server responses establish executable values.
23
+
24
+ ## Domain Model
25
+
26
+ - Application: the TD/OMS-managed software scope. Applications define environment and workflow context.
27
+ - Environment: a lifecycle location such as development, test, acceptance, emergency, or production. Actual codes and paths are site-defined.
28
+ - Request: a higher-level change or business request that may connect to tasks.
29
+ - Task/fix: the principal unit of assigned change work, lifecycle status, programmer ownership, and transfer control.
30
+ - Solution: a task-connected change record for an object/component.
31
+ - Object/component: a managed deployable or source-backed artifact. IBM i identity commonly includes object name, type, library, and optional member/detail.
32
+ - Source: editable content associated with a managed object or IFS item. Saves require current identity and concurrency markers.
33
+ - Branch/path: site-defined routing or isolation metadata controlling where work moves.
34
+ - Transfer: the controlled movement of task objects/solutions between lifecycle environments.
35
+ - Checkout: a transfer that brings eligible managed content into a development context.
36
+ - Promote: a transfer that advances completed work toward a later environment.
37
+ - Build queue/compile: asynchronous object creation work with queue state, compile results, event records, logs, and spool files.
38
+ - Ratification: an approval/rejection gate used for peer review, user acceptance, management approval, or another configured quality gate.
39
+ - Revision/conflict: archived or competing versions used for compare, history, and controlled resolution.
40
+
41
+ These relationships are stable concepts, but field names, statuses, reasons, transfer paths, and policy gates are configured per site.
42
+
43
+ ## Change Lifecycle
44
+
45
+ A robust agent workflow follows:
46
+
47
+ 1. Identify the application and current task/request.
48
+ 2. Read the assigned programmer, status, path, environment, objects, and relevant history.
49
+ 3. Discover allowed choices from the connected server.
50
+ 4. Connect or create the intended object/solution under the task.
51
+ 5. Read and edit source with concurrency protection.
52
+ 6. Compile and inspect terminal diagnostics.
53
+ 7. Review dependencies, conflicts, labels/comments, and required approvals.
54
+ 8. Prepare checkout/promote/transfer and inspect pre-transfer checks.
55
+ 9. Execute only after explicit approval.
56
+ 10. Monitor asynchronous work and verify final TD/OMS state.
57
+ 11. Complete or ratify only when site policy and observed state allow it.
58
+
59
+ This is a decision framework, not a universal site policy. The connected server remains authoritative.
60
+
61
+ ## Version And Site Variability
62
+
63
+ - TD/OMS and Octo evolve independently and expose different capabilities by release.
64
+ - Octo views and wizards are UI affordances; their visible fields may be populated by multiple TD/OMS APIs and database views.
65
+ - Some option lists are authoritative configuration reads. Others are inferred from values present in existing records and are marked non-authoritative by the MCP.
66
+ - Tracker integration, user options, compile overrides, templates, action groups, transfer checks, and ratification are especially site-specific.
67
+ - Internal or licensed REST documentation may be available to a user's organization. Use it when supplied, but do not reproduce confidential material in public skill output.
68
+
69
+ ## Public References
70
+
71
+ - [TD/OMS product overview](https://remainsoftware.com/tdoms/) describes TD/OMS as application lifecycle and change management across IBM i, Windows, and Unix/Linux, including development, test, acceptance, deployment, impact analysis, version history, and ratification.
72
+ - [Octo TD/OMS Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=remainsoftware.octo-tdoms) documents Work Management, task details, source editing, object connection, checkout/promote, build queue, spool files, IFS, revision compare, analytics, dependencies, and Kanban in Octo.
73
+ - [TD/OMS productivity](https://remainsoftware.com/td-oms-increases-alm-productivity/) provides conceptual background for impact analysis, compare/merge, controlled deployment, rollback, transfer logs, and multi-platform deployment.
74
+ - [TD/OMS collaboration](https://remainsoftware.com/td-oms-increases-alm-collaboration/) explains ratification as a configurable approval process used for peer review, acceptance, or promotion gates.
75
+ - [TD/OMS V17.0.1 release](https://remainsoftware.com/news/new-release-td-oms-v17-0-milestone-1-2/) documents Octo transfer history, version conflicts, impact analysis, compile results, and members in component views.
76
+ - [Web and VS Code TD/OMS V17.0.2 release](https://remainsoftware.com/news/new-release-web-and-vscode-td-oms-v17-0-milestone-2/) documents compile-error visualization, transfer/log history, compile overrides, transfer-path behavior, programmer assignment, ratification history, and build-queue integrations.
77
+
78
+ Public pages are contextual sources only. Always defer executable details to the live MCP schema and the connected TD/OMS server.
@@ -0,0 +1,150 @@
1
+ # Tool And Extension Map
2
+
3
+ ## Contents
4
+
5
+ - Runtime profiles
6
+ - Core interface
7
+ - Discovery option sets
8
+ - Core capability registry
9
+ - Full-profile families
10
+ - Octo extension comparison
11
+ - View replacements
12
+ - Intentional exclusions
13
+
14
+ ## Runtime Profiles
15
+
16
+ The standalone server has two profiles:
17
+
18
+ - `core`: 7 agent-neutral tools. Prefer this for broad client compatibility and limited tool budgets.
19
+ - `full`: 226 named tools in the audited release. Prefer this for typed direct actions, specialized reads, and developer diagnostics.
20
+
21
+ Counts are a release snapshot, not an API contract. Inspect the live MCP tool list and schemas before acting.
22
+
23
+ ## Core Interface
24
+
25
+ | Tool | Purpose |
26
+ | --- | --- |
27
+ | `tdoms_list_connections` | List saved local connection profiles without returning secrets. |
28
+ | `tdoms_get_current_context` | Resolve connection, TD/OMS username/programmer identity, applications, and environments. |
29
+ | `tdoms_list_capabilities` | Return workflow ids, option sets, required context, mode, support, and Octo wizard mapping. |
30
+ | `tdoms_discover_options` | Return normalized choices or structured records from TD/OMS. |
31
+ | `tdoms_plan_workflow` | Create a read-only mutation preview and ten-minute plan. |
32
+ | `tdoms_execute_workflow` | Revalidate and execute one approved plan. |
33
+ | `tdoms_get_workflow_status` | Read plan state and execution result. |
34
+
35
+ ## Discovery Option Sets
36
+
37
+ Discovery exposes 40 option sets. Use the exact runtime enum if it differs.
38
+
39
+ - Identity and configuration: `applications`, `environments`, `programmers`, `userClasses`.
40
+ - Task metadata: `taskStatuses`, `taskTypes`, `releases`, `priorities`, `completionReasons`, `ratificationReasons`.
41
+ - Change structure: `branchesPaths`, `taskObjects`, `solutions`, `solutionTypes`, `memberAttributes`, `labels`.
42
+ - Transfer and build: `transferTargets`, `subEnvironments`, `compileOverrides`, `conflicts`, `schedules`, `remoteJobs`.
43
+ - Creation and history: `objectTemplates`, `objectLocations`, `revisions`, `userOptions`, `trackerLinks`.
44
+ - Structured view reads: `tasks`, `requests`, `components`, `connectionLists`, `buildQueue`, `compileResults`, `transferHistory`, `logs`, `spoolFiles`, `trackerRecords`, `source`, `dependencies`, `dashboards`.
45
+
46
+ `OMSINFO/system`, `OMQRTO/select`, and `OMQRNO/location` results are authoritative for their returned choices. Several database-derived metadata lists are marked non-authoritative because they infer valid values from existing records. Respect `source.authoritative` in every response.
47
+
48
+ ## Core Capability Registry
49
+
50
+ The registry mirrors the 28 audited Octo wizards as structured workflows. It contains 24 supported mutations, 3 supported read-only capabilities, and 1 Octo-only unsupported capability.
51
+
52
+ | Workflow id | Mode | Required option sets or note |
53
+ | --- | --- | --- |
54
+ | `change-member-attribute` | Mutation | `memberAttributes` |
55
+ | `change-programmer` | Mutation | `programmers`, `userClasses` |
56
+ | `change-solution-type` | Mutation | `solutions`, `solutionTypes` |
57
+ | `change-task-transfer-path` | Mutation | `branchesPaths` |
58
+ | `compile-override` | Mutation | `compileOverrides`, `taskObjects` |
59
+ | `complete-task` | Mutation | `completionReasons` |
60
+ | `delete-objects` | Mutation | `taskObjects` |
61
+ | `disconnect-solutions` | Mutation | `solutions` |
62
+ | `display-message` | Read-only | Return message data; no window is opened. |
63
+ | `edit-branch` | Mutation | `branchesPaths` |
64
+ | `fill-object-file` | Mutation | `taskObjects` |
65
+ | `manage-label` | Mutation | `labels` |
66
+ | `link-issue-to-task` | Mutation | `trackerLinks` |
67
+ | `link-task-to-issue` | Mutation | `trackerLinks` |
68
+ | `move-solutions` | Mutation | `solutions`, `branchesPaths` |
69
+ | `new-object` | Mutation | `objectTemplates`, `objectLocations` |
70
+ | `new-task-branch` | Mutation | `branchesPaths` |
71
+ | `close-remote-job` | Mutation | `remoteJobs`, `completionReasons` |
72
+ | `reopen-remote-job` | Mutation | `remoteJobs` |
73
+ | `schedule-remote-job` | Mutation | `remoteJobs`, `schedules` |
74
+ | `revision-compare` | Read-only | `revisions` |
75
+ | `solution-conflict` | Read-only | Discover `solutions` and `conflicts`; resolution is site-specific. |
76
+ | `task-ratification` | Mutation | `ratificationReasons`, `programmers` |
77
+ | `tracker-server-manager` | Unsupported | Octo configuration; no known TD/OMS REST endpoint. |
78
+ | `transfer` | Mutation | `taskObjects`, `transferTargets`, `subEnvironments` |
79
+ | `unlink-task-from-issue` | Mutation | `trackerLinks` |
80
+ | `execute-user-option` | Mutation | `userOptions` |
81
+ | `resolve-version-conflict` | Mutation | `conflicts` |
82
+
83
+ The registry is not the complete full-profile capability list. For example, task creation, request creation, source saves, compile queue work, branch stash/restore/purge, and connection-list processing use full named tools.
84
+
85
+ ## Full-Profile Families
86
+
87
+ Prefer the most specific tool whose schema matches the operation.
88
+
89
+ - Context and connection: `tdoms_connection_*`, `tdoms_get_system_info`.
90
+ - Tasks: `tdoms_task_*`, `tdoms_create_task`, `tdoms_search_tasks`.
91
+ - Requests: `tdoms_request_*`.
92
+ - Solutions and objects: `tdoms_solution_*`, `tdoms_object_*`, `tdoms_component_*`.
93
+ - Source and IFS: `tdoms_read_source_all`, `tdoms_save_source_all`, `tdoms_patch_source_literal`, `tdoms_source_*`, `tdoms_ifs_*`.
94
+ - New objects: `tdoms_new_object_location`, `tdoms_new_object_create`, `tdoms_new_source_member_create`.
95
+ - Transfer: `tdoms_transfer_select_targets`, `tdoms_transfer_prepare`, `tdoms_transfer_execute_number`, `tdoms_transfer_progress_number`, plus typed checkout/promote tools.
96
+ - Compile: `tdoms_compile_and_check`, `tdoms_compile_*`, `tdoms_build_queue_*`, `tdoms_compile_override_*`.
97
+ - Branches: `tdoms_branch_*`.
98
+ - Connection lists: `tdoms_connection_list_*`.
99
+ - History and diagnostics: `tdoms_transfer_history`, `tdoms_log_*`, `tdoms_spool_*`, `tdoms_remote_job_*`.
100
+ - Governance and metadata: `tdoms_comment_*`, `tdoms_label_*`, `tdoms_user_option_*`, `tdoms_version_conflict_*`.
101
+ - Analysis and views: `tdoms_analysis_*`, `tdoms_dashboard_*`, `tdoms_kanban_*`, `tdoms_tracker_*`.
102
+ - Advanced: `tdoms_query_database`, administration tools, family `*_action` tools, and `tdoms_call_api`.
103
+
104
+ Specific typed tools should outrank family action tools. Family action tools should outrank `tdoms_call_api`.
105
+
106
+ ## Octo Extension Comparison
107
+
108
+ The extension audit was performed against Octo TD/OMS `1.5.1260701`. Its 95 tools were grouped as follows:
109
+
110
+ | Extension group | Count | Standalone relationship |
111
+ | --- | ---: | --- |
112
+ | Branch API | 7 | Covered by full `tdoms_branch_*`; selected branch workflows also have core plans. |
113
+ | Task API | 11 | Covered by full `tdoms_task_*`; selected task workflows also have core plans. |
114
+ | Database REST API | 1 | Covered by discovery and full `tdoms_query_database`. |
115
+ | Octo Views | 20 | Replaced by structured reads; no VS Code panel is opened. |
116
+ | Octo Wizards | 28 | Mapped into the core capability registry; tracker server manager remains Octo-only. |
117
+ | Octo local/context utilities | 28 | Mostly intentionally excluded; agents already provide generic text, crypto, and encoding utilities. |
118
+
119
+ The standalone MCP adds many REST operations that the extension exposes only indirectly through UI services or internal clients. It also adds option normalization, automatic connection-derived identity, token refresh, read-only planning, plan expiry, state revalidation, confirmation gates, and post-operation status reads.
120
+
121
+ Do not describe this as visual parity. It provides TD/OMS data and change-management parity where documented, not VS Code panels, editors, decorations, command-palette behavior, Octo mail, or Octo session management.
122
+
123
+ ## View Replacements
124
+
125
+ | Octo view intent | Core discovery or full named read |
126
+ | --- | --- |
127
+ | Work Management | `tasks`, `requests`; `tdoms_task_search`, `tdoms_request_search` |
128
+ | Branches | `branchesPaths`; `tdoms_branch_search`, `tdoms_branch_get` |
129
+ | Task Editor | `tdoms_task_details` or task-related option sets |
130
+ | Component Editor / Components | `components`, `taskObjects`; object/component detail tools |
131
+ | Solution Editor | `solutions`; `tdoms_solution_details` |
132
+ | Source Editor | `source`; `tdoms_read_source_all` |
133
+ | Spool source/files | `spoolFiles`; spool list/fetch tools |
134
+ | Build Queue | `buildQueue`; build-queue tools |
135
+ | Analytics | `dashboards`; dashboard and analysis tools |
136
+ | Connection List | `connectionLists`; connection-list tools |
137
+ | Dependency Graph | `dependencies`; analysis tools |
138
+ | Transfer History | `transferHistory`; transfer-history tools |
139
+ | Log History / Details | `logs`; log tools |
140
+ | Tracker | `trackerRecords`; tracker tools |
141
+ | Compile Result | `compileResults`; compile-result/error tools |
142
+ | Remote Job Monitor | `remoteJobs`; remote-job tools |
143
+
144
+ ## Intentional Exclusions
145
+
146
+ - Octo mail notification is not a TD/OMS change-management operation.
147
+ - Generic hashing, UUID, Base64, JSON, URL, time, byte-size, EBCDIC, and packed-decimal utilities are not duplicated.
148
+ - Tracker server administration remains Octo-only without a documented TD/OMS endpoint.
149
+ - UI-only navigation and editor state are not controlled.
150
+ - Site-specific behavior without an authoritative API choice is returned as unsupported instead of guessed.