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 +40 -0
- package/package.json +4 -1
- package/skills/tdoms-mcp-routing/SKILL.md +70 -29
- package/skills/tdoms-mcp-routing/agents/openai.yaml +4 -4
- package/skills/tdoms-mcp-routing/references/tdoms-domain-and-sources.md +78 -0
- package/skills/tdoms-mcp-routing/references/tool-and-extension-map.md +150 -0
- package/skills/tdoms-mcp-routing/references/workflow-playbooks.md +205 -0
- package/src/client-manager.js +347 -2
- package/src/index.js +38 -0
- package/src/storage-utils.js +4 -2
- package/src/ui-page.js +53 -8
- package/src/web-app.js +38 -0
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.
|
|
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:
|
|
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
|
-
|
|
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
|
-
##
|
|
10
|
+
## Load References Deliberately
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
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
|
-
|
|
16
|
+
## Establish Runtime Context
|
|
21
17
|
|
|
22
|
-
|
|
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
|
-
##
|
|
25
|
+
## Choose the Surface
|
|
25
26
|
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
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
|
-
##
|
|
34
|
+
## Read Workflow
|
|
33
35
|
|
|
34
|
-
|
|
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
|
-
|
|
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
|
-
##
|
|
46
|
+
## Planned Mutation Workflow
|
|
39
47
|
|
|
40
|
-
|
|
48
|
+
Follow this sequence for every supported core mutation:
|
|
41
49
|
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
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
|
-
|
|
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
|
|
3
|
-
short_description: "
|
|
4
|
-
default_prompt: "Use $tdoms-mcp-routing to
|
|
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.
|