Sent Items: search returns hit count but no message details (subject, recipients, date)
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 1k
- Forks
- 132
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 6
Description
GitHub Issue für Work IQ MCP
Title (kopiere dies in das Title-Feld):
Sent Items: search returns hit count but no message details (subject, recipients, date)
Body (kopiere alles unterhalb dieser Linie in das Body-Feld):
Summary
When querying sent emails via Work IQ (CLI or MCP), the search backend confirms the existence and count of matching messages in the Sent Items folder, but does not return message-level details (subject, recipients, sent date). This makes it impossible to build AI-powered assistants that need a complete view of a user's email activity — not just what they received, but also what they sent.
Environment
- Work IQ version: 0.2.8
- Platform: Windows (win_x64)
- Usage mode: CLI (
workiq ask -q "...") and MCP server - Tenant: Microsoft internal (Entra ID, corporate M365)
Steps to Reproduce
-
Run a query targeting sent emails:
workiq ask -q "What emails did I send today and yesterday? Show me the subject of each email." -
First attempt — Work IQ correctly identifies that emails exist:
"Total results: 8 sent emails in the last two days."
But then states:
"The search service returned the count, but did not return the individual email details (subjects, recipients, or sent dates)."
-
Second attempt with a rephrased prompt — Work IQ returns what appear to be email subjects, but they are hallucinated. The AI model fabricates plausible-sounding subjects instead of admitting it lacks the data. The user only discovers this after manually cross-checking with Outlook.
Expected Behavior
Work IQ should return the same level of detail for Sent Items as it does for Inbox messages — at minimum: subject, recipients (To/CC), and sent datetime. If the data cannot be retrieved, the response should clearly state this limitation without fabricating results.
Actual Behavior
| Query target | Hit count | Message details (subject, to, date) |
|---|---|---|
| Inbox / received emails | ✅ Returned | ✅ Returned |
| Sent Items | ✅ Returned | ❌ Not returned |
When message details are unavailable, the AI model sometimes hallucates fake email subjects instead of transparently communicating the limitation. This is a serious trust and reliability issue.
Why This Matters
For anyone building an intelligent assistant or agent on top of Work IQ (which is its stated purpose), read-only access to Sent Items is essential. Real-world use cases that are currently broken:
- Daily briefing tools — "What did I work on yesterday?" requires both received and sent email context
- Meeting preparation — "What did I last write to this person?" needs Sent Items
- Task tracking — Identifying follow-ups and commitments the user made via email
- Accountability/audit — "Did I reply to that thread?" requires Sent Items visibility
An assistant that can only see what was received but not what was sent has an incomplete picture and cannot reliably answer questions about the user's own activity.
Technical Analysis
The root cause appears to be that Work IQ relies on the Microsoft Search API for email queries, which returns search hits but with limited metadata — especially for Sent Items. In contrast, the built-in Microsoft 365 Copilot (available in Outlook/Teams) handles identical queries flawlessly because it uses:
- The Graph Messages API (
/me/mailFolders/SentItems/messages) with full OData filtering - The Semantic Index for Copilot with richer metadata
- First-party app privileges with
Mail.Readdelegated scope
A possible path forward could be:
- Request
Mail.Read(delegated) scope for the Work IQ app registration, enabling direct Graph API access to/me/messagesand/me/mailFolders/SentItems/messages - Fall back to Graph Messages API when Microsoft Search returns hits without message-level details
- Prevent hallucination — if message details are unavailable, always return a clear error rather than letting the AI model fabricate content
Additional Context
The hallucination issue (fabricating email subjects) is particularly concerning because the user has no way to distinguish real from fake results without manually verifying in Outlook. For a tool that handles sensitive corporate email data, accuracy must take precedence over appearing helpful.
Disclosure
I'm a Microsoft employee (FTE) testing Work IQ on our internal corporate tenant. Happy to provide additional diagnostics or collaborate with the product team internally — feel free to reach out via Microsoft Teams.
Tested on Work IQ v0.2.8, Windows 11, Microsoft corporate tenant, February 2026.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the workiq ask -q sent-email query path and compare its Microsoft Search API results with the mentioned Graph endpoints for SentItems messages. Done means sent messages expose subject, recipients, and sent date like Inbox results, or the response explicitly reports unavailable details without fabricating them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- powershell
- Domain
- api, backend-api-design, cli, search
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100