Single tool with acceptable structure but significant gaps. Tool name follows verb-noun convention (wait_for_sponsor_dm) but is highly specialized and domain-specific. Input schema is present with proper types (timeout_seconds: integer, poll_interval_seconds: number) and descriptions are adequate but brief. The tool description (95 chars) explains the core function clearly but lacks critical operational details like retry behavior, error states, and what exactly is returned on success vs timeout. No output schema is documented in the source code, forcing LLMs to infer the response structure. The tool appears idempotent and read-only but lacks explicit schema documentation for the structured message data it claims to return. Code shows thoughtful progress messaging and animation frames, but these implementation details are invisible to the MCP protocol layer.

• Document the complete output schema. Define the structure of the 'structured message data' returned on success: include all fields (sender_id, sender_name, message_text, timestamp, channel_id, etc.), their types, and when each is present.
• Expand the tool description to 150-250 characters covering: (1) Primary use case ('Wait for a specific team member to send a DM in Teams before proceeding'), (2) Timeout behavior ('Returns timeout status if no message arrives within the specified window'), (3) Sponsor gating ('Only messages from authorized sponsors are returned; other messages are filtered'), (4) When to use it ('Call this when the agent needs human approval or a sponsor-provided input before continuing').
• Add numeric constraints to parameters. For timeout_seconds: add min=1, max=86400 (24 hours). For poll_interval_seconds: add min=0.5, max=300 (reasonable polling range). Document these in the parameter descriptions.
• Add explicit error guidance. Document possible failures: 'If Teams API is unavailable, returns error with retry guidance. If timeout expires, returns status="timeout" with null message data. If caller lacks Teams credentials, returns authentication_required error.'
• Consider adding an optional parameter like 'sponsor_id' or 'sponsor_filter' to scope the wait to specific senders, making the tool more flexible for multi-sponsor workflows.
• Document whether repeated calls with the same sponsor context are idempotent or if calling twice in quick succession risks missing the first message due to dedup logic (DEDUP_MAX=1000 is in code but not visible to LLM).

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry