MCP server for Microsoft Teams integration with information retrieval capabilities, message search, and content indexing
This server has 11 tools with significant definition quality gaps. While most tools have basic descriptions and input schemas, the schemas are inconsistently detailed, descriptions lack LLM-optimization guidance, and critical error handling is absent. The tool set shows conceptual coherence (search, indexing, messaging) but suffers from vague naming, incomplete parameter documentation, and missing output schema specifications. Only 3 tools have truly adequate schema completeness; most others lack proper constraints and validation guidance. No tool provides error recovery hints or actionable failure modes.
Delete indexed content.
Get count of indexed content.
Get recent messages from a specified chat, store in DuckDB with embeddings.
Index a piece of content.
Index messages from Teams.
Perform information retrieval search via HTTP to the IR server.
List all Teams chats the agent is a member of and store in DuckDB.
Three distinct search tools (search, search_messages, search_messages_llm_rerank, ir_search) with overlapping functionality and unclear differentiation. LLMs will struggle to select the correct one.
No output schemas documented for any tool. LLMs cannot predict what fields to expect or plan downstream tool chaining. Baseline: 100% of A+ tools document return types.
No error handling guidance. Tools do not indicate which errors are retryable, user-fixable, or fatal. No recovery hints (e.g., 'Try search_chats() if chat_id is unknown'). Baseline: pattern:recovery-guide requires actionable error responses.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Search indexed content.
Hybrid search over messages: mode can be 'bm25', 'vector', or 'hybrid'.
Advanced search with LLM reranking: first retrieves candidates with hybrid search, then optionally uses LLM to rerank results based on query relevance.
Send a message to a specified chat.
delete_content is a destructive operation but lacks a dry-run/confirmation step. No mention of pre-confirmation or safety warnings. Agents can delete data with a single call.
Descriptions for index_teams_messages, delete_content, search_messages_llm_rerank are under 50 characters. LLMs need concrete context about when to use each tool. Baseline: A+ tools have 50 - 200 character descriptions.
Parameter constraints missing or implicit. E.g., search_type enum values (hybrid, semantic, fulltext) are documented, but search_messages_llm_rerank mode enum values are not formally declared. No validation guidance in descriptions.
Tool names do not clearly distinguish scope. 'search' is generic; 'search_messages' clarifies, but 'ir_search' is vague. Naming should indicate: teams message search vs. indexed content search vs. external IR service.
Pagination guidance is minimal. search, search_messages, ir_search support limit/offset, but descriptions do not state default limits, maximum limits, or recommend result caps. Baseline: tools should cap results at 20 - 50 and document pagination explicitly.
Missing chain-friendly IDs. E.g., get_messages may return message IDs but unclear if downstream tools (search_messages, delete_content) accept those IDs in compatible formats. Response schemas would clarify.
No permission scopes documented. Destructive tools (delete_content) and write tools (index_content, send_message) should declare required permissions (e.g., 'write:content', 'write:messages') for least-privilege agent configuration.
Optional parameters (source_type, since, metadata, filters) lack guidance on mutual exclusivity or dependencies. LLMs may pass invalid combinations without explicit constraints.