hook-runner cannot invoke deferred Jira MCP tools: missing ToolSearch/GetMcpTools in tools: list

[joedavis-oura]

Symptoms

The before-implement hooks step for EAC-2781 (context file
/Users/joe.davis/vscode/.dev-team/jouzen/ent-inventory-api/EAC-2781.md) failed. The
dev-team:hook-runner agent was dispatched with instructions ["Set Jira work item status to \"In Progress\"", "Set \"Assignee\" to myself"] and reported it could not execute either Jira
operation.

The agent invoked work-with-Jira-tasks (plugins/dev-team/skills/work-with-Jira-tasks/SKILL.md)
several times with different argument shapes and only ever got the skill's own documentation
back, never an executed Jira operation. Root cause: work-with-Jira-tasks's primary discovery
path calls ToolSearch(query="<operation-suffix>") to load a matched MCP tool's schema before
it can be invoked, with a documented GetMcpTools/CallMcpTool fallback for environments where
ToolSearch doesn't surface individually-named tools. Neither ToolSearch nor
GetMcpTools/CallMcpTool appears in plugins/dev-team/agents/hook-runner.md's tools: list —
only Read, Bash, Skill, and the mcp__jira__* / mcp__plugin-atlassian-atlassian__* /
mcp__claude_ai_atlassian-* / mcp__plugin_github_github__* wildcard grants.

In this occurrence, the connected Atlassian MCP server (mcp__claude_ai_atlassian-ouraring__*)
exposes its Jira operations as deferred tools — the runtime requires a ToolSearch call to load
a deferred tool's schema before it becomes callable, even though the wildcard grant in
hook-runner.md already covers the tool's name. Without ToolSearch (or the GetMcpTools/
CallMcpTool fallback) in its own tool list, hook-runner has no way to ever invoke a deferred
Jira MCP tool, regardless of what its wildcard grants otherwise permit — so every Jira operation
dispatched through work-with-Jira-tasks from hook-runner fails in this class of environment.

This surfaced through workflow-orchestrate's "any non-successful hook result runs the
troubleshooter" rule (plugins/dev-team/skills/workflow-orchestrate/SKILL.md), even though
dev_team.py's own hook-phase handling (_do_get_actions_and_exit, dev_team.py:1171-1264)
already tolerates a failed hook and advances hook_phase from before to main on the very
next invocation regardless of outcome — this before-implement hook is Jira bookkeeping only
(status transition + assignee) and does not block EAC-2781's actual implementation.

Workaround

None applied to the pipeline mechanics — no context-file edit was needed. dev_team.py already
advances past a failed before-hook on its next invocation (moving hook_phase from before to
main, then dispatching the step's own main action), so the fix here is simply to let the
pipeline continue past this hook failure rather than block on it: return continue to the
orchestrator without retrying the Jira operations. EAC-2781's Jira status/assignee will not
reflect "In Progress"/self-assigned until this is fixed or done manually.

A real fix would add ToolSearch (and, per work-with-Jira-tasks's documented fallback,
GetMcpTools/CallMcpTool) to hook-runner.md's tools: list, matching what
work-with-Jira-tasks's discovery procedure actually requires. Not attempted in this occurrence
at the user's direction (skip Jira bookkeeping, continue implementation) and because
troubleshooter.can-fix/can-push-fix are unset in this project's merged configuration.

Written by dev-team troubleshooter agent