Repository navigation
Description
Describe the bug
I struggle with this every single day. I'll come back to a session (not even resuming it, simply sitting back down at the keyboard) and for whatever reason it is unable to access certain MCP tools.
Thankfully, I learned that /compact will allow the tools to be visible again, but this is a significant tax to pay in time and lost context.
Take the following flow
Tools were working fine, return to session this morning and ask a follow-up question
"The WorkIQ email search/read tools used earlier are currently unavailable"
Tried "/mcp show workiq" and see all the tools myself so I ask it to try again
"Retried discovery; WorkIQ currently exposes no tools"
Tried "/mcp reload"
"tool discovery still returns zero WorkIQ tools after the reload"
Tried "/compact"
"WorkIQ discovery now returns tool definitions, including fetch , retrieve , search_paths , and get_schema . Tool visibility is restored"
And here is another where I tried to use /diagnose to get more info -
Diagnosis: WorkIQ did not fail. Its tool manifest was dropped from this agent’s available-tool set between turns.
┌─────────────┬────────────────────────────────────────────────────────┬─────────────────────────────────────────┐
│ Time │ Evidence │ Meaning │
│ (local) │ │ │
├─────────────┼────────────────────────────────────────────────────────┼─────────────────────────────────────────┤
│ 10:29 │ workiq-fetch was present and completed successfully │ Message reading worked. │
│ │ (call_MRBxgCMrDu4CAMXOEfWKz0PX). │ │
├─────────────┼────────────────────────────────────────────────────────┼─────────────────────────────────────────┤
│ 10:31 │ workiq-ask was present and completed successfully │ WorkIQ remained reachable. │
│ │ (call_n9juETP7XLTU8NXR8OsYYPWz). │ │
├─────────────┼────────────────────────────────────────────────────────┼─────────────────────────────────────────┤
│ 14:35 │ Only workiq-call_function was provided; its call │ The MCP server was alive; that endpoint │
│ │ reached WorkIQ and returned a normal Graph BadRequest │ was simply unsuitable. │
│ │ because message delta is unsupported. │ │
├─────────────┼────────────────────────────────────────────────────────┼─────────────────────────────────────────┤
│ 14:43-14:45 │ Tool-registry lookups for workiq returned Found 0 │ The agent-side discovery/manifest layer │
│ │ tools. │ had no WorkIQ schemas, despite the │
│ │ │ CLI’s /mcp show listing them. │
└─────────────┴────────────────────────────────────────────────────────┴─────────────────────────────────────────┘
There is no WorkIQ crash, transport failure, or authorization failure recorded in the session log. The historical MCP log also shows successful tools/list responses advertising fetch . The failure is therefore most likely in tool-manifest hydration/caching or dynamic tool filtering between the CLI MCP registry and this agent context. The session log does not record the upstream decision that removed those schemas, so it cannot establish the exact root cause.
My error was treating the missing manifest as a WorkIQ outage. The correct statement was: the agent lost the WorkIQ schemas while the WorkIQ MCP remained available.
Compaction completed
A new checkpoint has been added to your session.
Use /session checkpoints 5 to view the compaction summary.
Check again now, I have just compacted you and that usually brings the tools back.
Thought for 5s
I can see the full WorkIQ tool set again, including fetch , retrieve , and message update/delete operations.
Affected version
1.0.103
Steps to reproduce the behavior
I don't know a direct way to repro. Just happens over time, but happens frequently and has happened for months.
Expected behavior
No response
Additional context
No response
Activity