feat(codegen): derive tool name from path when operationId is absent

[johnxie]

Why

The codegen assumed every OpenAPI operation has an operationId (parser.ts: operation.operationId!). True for Taskade API v1 — but v2 has 45 operations and zero operationIds (verified against /api/documentation/v2/json), so every v2 tool name would be undefined and nothing would register. This is the prerequisite that unblocks porting v2 into the MCP server.

What

• deriveToolName(method, path): strips path params ({id}), camelCases remaining segments (POST /promptAgent → promptAgent; GET /media/{mediaId}/content → mediaContent), falls back to the HTTP method for a root path.
• parser.ts: name: operation.operationId ?? deriveToolName(method, path) and description: operation.description ?? operation.summary ?? ''.
• New parser.test.ts (5 cases).

Zero-regression

• v1 is unaffected — it has operationIds, so the ?? fallback never fires. Verified: the v1 test asserts operationId still wins.
• yarn lint clean; all tests pass (existing normalizeAllOf/runtime + new parser).
• Pure addition to @taskade/mcp-openapi-codegen; no change to the generated v1 tool set.

Next in the chain

• PR-2: fix the dead v1 spec fetch URL.
• PR-3: add the v2 tool layer (agent chat + webhooks) using this fallback. (Heads-up surfaced during testing: the live v2 spec has a broken $ref in Field.data.fillerConfig.sourceRef that makes dereference() throw — PR-3 will bundle-not-dereference or prune; tracking separately.)

[changeset-bot]

🦋 Changeset detected

Latest commit: 123e6d7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@taskade/mcp-openapi-codegen	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[johnxie]

Review follow-up

Ran /pr-review-toolkit:review-pr (code-reviewer + pr-test-analyzer) and the /code-review scored pass on this change. Posting the result for visibility — cc @deanzaka @lxcid.

Verdict: no blocking issues. Zero v1 regression — every v1 operation carries an operationId, so ?? short-circuits and deriveToolName never fires for v1; tools.generated.ts is byte-identical.

Validated:

• deriveToolName run over all 45 live v2 operations → 0 operationIds, 45 unique names, 0 empty/malformed (e.g. POST /promptAgent → promptAgent, /media/{mediaId}/content → mediaContent).
• Edge cases: / → get, /api_keys & /api-keys → apiKeys, path params dropped.

Two test-coverage gaps the analyzer flagged here are now closed in #55: the /[-_]/ kebab/snake segment split and the ?? '' empty-description tail now have explicit assertions in parser.test.ts.

Non-blocking, for later: the derived name excludes the HTTP method, so a REST-style spec with GET /x + POST /x would collide. Not reachable on v2 (flat, distinct RPC paths), but worth a duplicate-name guard in parseOpenApi if we ever feed REST specs through this path.

parser.ts deriveToolName