这是一个开源的“模型上下文协议”(MCP) 服务器，用于将 Claude AI 连接到 Viva Engage (Yammer)。通过与 Claude 的自然对话，您可以浏览家庭网络社区、搜索帖子、阅读对话并发布回复。
由 Pranav Joshi 构建
连接后，您可以询问 Claude 诸如：
“我属于哪些 Viva Engage 社区？”
“搜索关于 Business Central 错误的帖子”
“开发者社区中最新的对话是什么？”
“回复该主题，内容为……”
“向我展示我的 Viva Engage 信息流”
Related MCP server: linkedin-mcp-server
此 MCP 服务器仅适用于您的家庭网络（即与您的登录凭据绑定的主要组织网络）。
为什么它无法访问外部网络？
Viva Engage 支持两种类型的网络：
家庭网络 — 您的主要组织（例如您公司的 Viva Engage）
外部网络 — 您作为访客成员加入的其他组织托管的社区（例如 Microsoft 的 BC Partners 社区）
无论使用什么参数或令牌，Yammer REST API (www.yammer.com/api/v1) 都仅返回来自您家庭网络的数据。外部网络需要仅在完整的基于 Web 的登录后才能获得的浏览器会话 Cookie，而这无法仅通过 API 调用来复制。
Microsoft 较新的 Graph API (graph.microsoft.com) 也不支持外部网络 — 它仅适用于您自己租户内处于原生模式的网络。
这是 Microsoft API 的限制，而非此 MCP 服务器的限制。如果 Microsoft 未来扩展其 API 以支持外部网络，此服务器可以进行更新以提供支持。
You ask Claude a question
↓
Claude calls this MCP server
↓
Server calls Viva Engage API using YOUR login
↓
Returns data only YOU can already see
↓
Claude answers your question隐私： 每个用户注册自己的 Azure 应用并使用自己的 Microsoft 凭据。数据绝不会通过任何其他人的基础设施。您的登录令牌仅加密存储在您的机器上。
Node.js v18 或更高版本
具有 Viva Engage 访问权限的 Microsoft 工作/学校账户
这是一个一次性设置（约 10 分钟）。您可以在自己的 Microsoft 账户下注册自己的应用。其他人无法使用您的应用 — 它仅与您的凭据绑定。
前往 portal.azure.com 并使用您的 Microsoft 工作/学校账户登录
搜索 “应用注册” (App registrations) → 点击 “+ 新注册” (+ New registration)
填写：
名称： mcp-viva-engage（或任何您喜欢的名称）
支持的账户类型： 多个 Entra ID 租户 → 选择 允许所有租户
重定向 URI：
平台 = 公共客户端/原生 (移动和桌面)
URI = http://localhost
点击 “注册” (Register)
在概览页面上，复制并保存以下两项：
应用程序 (客户端) ID
目录 (租户) ID
在左侧边栏中点击 “API 权限” (API permissions)
点击 “+ 添加权限” (+ Add a permission) → 点击 “所有 API” (All APIs) 选项卡 → 搜索 “Yammer”
点击 “Yammer” → 点击 “委托的权限” (Delegated permissions)
勾选以下四项权限：
✅ user_impersonation
✅ Community.Read.All
✅ EngagementConversation.ReadWrite.All
✅ Storyline.ReadWrite.All
点击 “添加权限” (Add permissions)
工作/学校账户注意事项： 在您首次登录之前，您组织的 IT 管理员可能需要为此应用授予许可。这是一个一次性步骤。您在首次运行服务器时，可以直接从登录屏幕提交批准请求。
# Clone the repo
git clone https://github.com/pranav4186/mcp-viva-engage.git
cd mcp-viva-engage
# Install dependencies
npm install
# Build
npm run build复制示例 env 文件：
# Windows
copy .env.example .env
# Mac/Linux
cp .env.example .env打开 .env 并填入您在第 1 步中获取的值：
AZURE_CLIENT_ID=your-application-client-id-here
AZURE_TENANT_ID=your-directory-tenant-id-here重要： 切勿将您的
.env文件提交到 GitHub。它已包含在.gitignore中以防止这种情况。
打开您的 Claude Desktop 配置文件：
Windows： %APPDATA%\Claude\claude_desktop_config.json
Mac： ~/Library/Application Support/Claude/claude_desktop_config.json
将 viva-engage 服务器添加到 mcpServers 部分：
{
"mcpServers": {
"viva-engage-mcp": {
"command": "node",
"args": ["C:/path/to/mcp-viva-engage/dist/server.js"],
"env": {
"AZURE_CLIENT_ID": "your-application-client-id-here",
"AZURE_TENANT_ID": "your-directory-tenant-id-here"
}
}
}
}将
C:/path/to/mcp-viva-engage替换为您克隆存储库的实际路径。 Windows 路径可以使用正斜杠/或双反斜杠\\。
保存后，请完全退出并重启 Claude Desktop。
当您第一次向 Claude 询问有关 Viva Engage 的内容时：
会自动打开一个浏览器窗口，显示 Microsoft 登录页面
使用您的 Microsoft 工作/学校账户登录
批准权限
浏览器显示 “登录成功！” (Login successful!)
Claude 完成您的请求
您的会话会加密保存在您的机器上。当您重启 Claude Desktop 时，可能需要再次登录。
工具 | 描述 |
| 获取您所属的所有 Viva Engage 网络 |
| 列出您家庭网络中的所有社区 |
| 通过 ID 获取特定社区的详细信息 |
| 获取特定社区中的所有帖子 |
| 获取对话主题中的所有消息 |
| 在您的家庭网络中搜索帖子 |
| 向社区发布新消息 |
| 回复现有的对话主题 |
| 获取您的个人 Viva Engage 故事线信息流 |
🔐 您自己的 Azure 应用 | 每个用户注册自己的应用 — 无共享基础设施 |
🔐 您自己的凭据 | 您使用自己的 Microsoft 账户登录 |
🔐 加密令牌存储 | 令牌使用 Windows DPAPI（或 Mac/Linux 上的纯文件）加密 |
🔐 代码中无密钥 | 客户端 ID 和租户 ID 仅保留在您的本地 |
🔐 委托权限 | 服务器只能看到您在 Viva Engage 中已经能看到的内容 |
🔐 从不触碰密码 | Microsoft 完全处理身份验证 |
mcp-viva-engage/
├── src/
│ ├── auth/
│ │ └── auth.ts # Microsoft OAuth login with DPAPI encrypted cache
│ ├── yammerClient.ts # Viva Engage / Yammer API client
│ └── server.ts # MCP server and tool definitions
├── .env.example # Template — copy to .env and fill in your values
├── .gitignore # Prevents .env from being committed
├── package.json
├── tsconfig.json
└── README.md首次登录时显示“需要批准”
您的组织要求对新应用进行管理员许可。请要求您的 IT 管理员在 Azure 门户 → 企业应用程序 → 找到
mcp-viva-engage→ 授予管理员许可。这是一次性操作。
Claude Desktop 中未显示服务器
编辑配置文件后，请完全退出并重启 Claude Desktop。验证
dist/server.js的路径是否正确。
重启后需要再次登录
加密令牌可能已过期。只需再次登录即可 — 登录后会话将被缓存。
仅看到家庭网络社区
这是预期的 — 请参阅上方的 重要限制 部分。Yammer REST API 仅支持家庭网络访问。
Windows 上的路径问题
在配置文件中使用正斜杠
C:/path/to/dist/server.js或双反斜杠C:\\path\\to\\dist\\server.js。
仅限家庭网络 — 无法通过任何公共 Microsoft API 访问外部网络（例如 Microsoft BC Partners 社区）。请参阅上方的解释。
速率限制 — Yammer API 允许每个用户每个应用每 30 秒 10 次请求。
只读搜索 — 搜索结果仅限于 Viva Engage 索引的内容。
[ ] 转换为远程连接器，以便用户无需本地设置
[ ] 为大型社区信息流添加分页支持
[ ] 支持 Windows 凭据管理器，以实现更安全的令牌存储
[ ] 如果 Microsoft 未来添加 API 支持，则支持外部网络
MIT — 详情请参阅 LICENSE。
这是一个独立的开源项目，不隶属于 Microsoft 或 Viva Engage，也不受其认可或支持。使用风险自负。
Get all Viva Engage communities/groups the user is a member of in their home network
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states it returns communities but lacks details on pagination, authentication requirements, or response shape. For a no-parameter tool, the description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and concise with no unnecessary words. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description adequately states what it does. Could mention scope (home network) but that is already included. Complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline is 4. Description adds no parameter info, which is appropriate as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves all Viva Engage communities the user is a member of in their home network. Distinguishes from siblings like get_community_by_id (single community) and get_networks (networks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all member communities, but does not provide explicit guidance on when to use this vs alternatives like get_community_by_id for a specific community.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Viva Engage community by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | The ID of the community/group |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get details,' which implies a read operation but does not explicitly confirm read-only nature, side effects, or any required permissions. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that contains all essential information without any filler or repetition. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no nested objects, no output schema), the description is adequate but lacks any indication of the response format or fields returned. It could be more complete by mentioning what 'details' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage—the parameter 'group_id' is described as 'The ID of the community/group' in the schema. The description does not add additional meaning beyond what the schema already provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get details), the resource (Viva Engage community), and the method (by its ID). It distinguishes itself from sibling 'get_communities' which likely lists all communities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific community ID, but it does not explicitly state when to use this tool versus alternatives like 'get_communities' or 'get_community_messages'. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all messages/posts in a specific Viva Engage community in the home network
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | The ID of the community/group |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It indicates a read operation but omits details on pagination, sorting, filtering, authentication, rate limits, or what happens if the community is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-front-loaded sentence with no redundant words. Every part earns its place: verb, resource, community scope, and network qualification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and no output schema, the description provides adequate purpose but lacks details on return format, limits, or ordering. It is sufficient for basic use but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes group_id as 'The ID of the community/group' (100% coverage), so the description adds little beyond reaffirming the context. Baseline 3 applies; the mention of 'home network' adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'messages/posts', and the scope 'in a specific Viva Engage community in the home network'. It distinguishes from siblings like get_thread (single thread) and post_message (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as search_messages or get_thread. No explicit usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all Viva Engage networks the user belongs to
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states operation without any behavioral traits like read-only, side effects, or rate limits. For a simple read, minimal but missing explicit safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single straightforward sentence with zero waste. Front-loads the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simplest tool, description explains what it returns (all networks user belongs to). Could mention output format or authentication, but context is adequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (0 params), so baseline is 4. Description adds no additional param info, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly uses verb 'Get' and resource 'networks', specifying scope 'the user belongs to'. It distinguishes from siblings like get_communities which are different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not explicitly state when to use this tool vs alternatives, but the purpose is clear and siblings are distinct, so no immediate confusion. Still, lacks any usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current user's Viva Engage storyline/personal feed
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the function name. It doesn't disclose any behavioral aspects like authentication requirements, data freshness, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no parameters, the description is adequate but could be improved by mentioning that it returns the feed for the authenticated user, especially since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description adds no extra semantics beyond confirming it's a parameterless call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Viva Engage storyline/personal feed', which is distinct from sibling tools like get_communities or get_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided, but the purpose is clear enough that the agent can infer it's for retrieving the current user's personal feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all messages in a specific conversation thread
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | The ID of the thread to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as read-only nature, pagination, error handling, or rate limits. The 'get' verb implies reading but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. No redundant information, but could be more structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing crucial details: What does the output contain? Is there ordering or filtering? No output schema, so description should compensate. Incomplete for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the sole parameter, so the schema already explains it. The description adds no further semantics beyond restating the parameter role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all messages in a specific thread, using a specific verb and resource. It distinguishes from sibling tools like get_community_messages but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_community_messages or search_messages. Missing context on prerequisites or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new message to a Viva Engage community
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | The ID of the community to post to | |
| body | Yes | The content of the message to post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must disclose side effects. Does not mention mutation, rate limits, formatting, or success/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficient for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a creation tool. No mention of return value, error cases, or community identification. With sibling reply_to_message, should differentiate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no extra parameter context beyond 'post to a community', so baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Post a new message to a Viva Engage community'. Specific enough but lacks detail on message type and doesn't differentiate from sibling reply_to_message explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives like reply_to_message. No mention of prerequisites (e.g., obtaining group_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing message or conversation thread
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | The ID of the message or thread to reply to | |
| body | Yes | The content of the reply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies write operation but lacks detail on behavior (e.g., quotting, character limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for basic understanding but missing behavioral details that would aid an agent (e.g., markdown support, permissions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Tool description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'reply' and resource 'existing message or conversation thread'. Distinguishes from siblings like post_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not specify when to use vs alternatives (e.g., post_message for new threads). No context on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for posts and messages across all communities in the home network
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search term or question to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It indicates search across all communities but omits critical details such as read-only nature, rate limits, response format, pagination, or authentication requirements, which are essential for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose with no superfluous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is minimally viable but lacks behavioral context such as search behavior (e.g., case sensitivity, full-text), result limits, or how results are structured. Sibling tools exist but are not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so baseline is 3. The description adds context about the search scope (across all communities) but does not enhance the parameter's meaning beyond the schema's 'search term or question'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for posts and messages across all communities in the home network, providing a specific verb and resource scope. It effectively distinguishes itself from sibling tools like get_community_messages or get_thread, which operate on narrower contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The scope is implied by contrasting with siblings (e.g., get_community_messages for a specific community), but the description does not state exclusions or provide direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_communitiesget_community_by_idget_community_messagesget_networksget_storyline_feedget_threadpost_messagereply_to_messagesearch_messagesScored across 9 tools
Each tool targets a distinct resource or action: communities are separate from messages, threads, feeds, and networks. No apparent overlap between tools like get_community_messages and get_thread, as one fetches all posts in a community and the other retrieves a specific conversation thread.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_communities, post_message, search_messages). No mixing of styles or vague verbs.
With 9 tools covering communities, messages, threads, networks, feeds, and search, the count is well-scoped for a social engagement platform. Each tool serves a clear purpose without unnecessary redundancy.
The tool set covers core read and write operations for communities and messages, including posting and replying. However, it lacks update and delete functionality for messages, which is a minor gap for full lifecycle management.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Your own WhatsApp in Claude and ChatGPT: read chats, draft replies, send messages you approve.
Your professional network in Claude — search contacts, log notes, and send warm intros.
LinkedIn outreach from Claude with a human veto. Gigi researches each prospect and drafts the connection request and follow-ups; from Claude you review, edit and approve drafts, triage replies, create and manage campaigns, and read outreach reports. Nothing is sent without an approval, every write tool asks first, and the connector cannot bypass LinkedIn caps or sending windows. Sign-in: OAuth with your Gigi account. Setup: https://usegigi.ai/connect-claude?ref=glama
