What can you do with this server?

This server connects Claude AI to Viva Engage (Yammer), enabling you to browse, search, read, and interact with your home network communities through natural language. * Get Networks – List all Viva Engage networks you belong to * Get Communities – List all communities you are a member of, or fetch details for a specific community by ID * Get Community Messages – Read posts from a specific community by name or ID, with pagination support * Get Thread – Retrieve all messages within a specific conversation thread * Search Messages – Find posts across your home network by keyword, with optional date filtering * Post Message – Publish a new message or announcement to a community by name or ID * Reply to Message – Reply to an existing message or conversation thread * Get Storyline Feed – View your personal Viva Engage storyline feed * Get Recent Activity – Scan all communities for recent messages in one call Note: All tools are restricted to your home network only; external networks are not accessible due to Microsoft API limitations.

How do I use mcp-viva-engage?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-viva-engage What communities am I a member of?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

mcp-viva-engage

by pranav4186

Overview Schema Related Servers Score Discussions

TypeScript

Local

mcp-viva-engage

An open source Model Context Protocol (MCP) server that connects Claude AI to Viva Engage (Yammer). Browse your home network communities, search posts, read conversations, and post replies — all through natural conversation with Claude.

Built by Pranav Joshi

What You Can Do

Once connected, you can ask Claude things like:

"Summarize what's new in all my communities today"
"What is new in ISV Collaboration this week?"
"Find all posts about AL Extensions this week"
"What are the latest conversations in the Developers community?"
"Post an announcement to the Business Central community"
"Search for posts about Business Central errors"
"Show me my Viva Engage feed"

Related MCP server: linkedin-mcp-server

Important Limitation — Home Network Only

This MCP server works with your home network only (the primary organization network tied to your login credentials).

Why can't it access external networks?

Viva Engage supports two types of networks:

Home network — your primary organization (e.g. your company's Viva Engage)
External networks — communities hosted by other organizations you're a guest member of (e.g. Microsoft's BC Partners community)

The Yammer REST API (www.yammer.com/api/v1) only returns data from your home network regardless of what parameters or tokens are used. External networks require browser session cookies that are only available after a full web-based login — something that cannot be replicated through API calls alone.

Microsoft's newer Graph API (graph.microsoft.com) also does not support external networks — it only works with networks in native mode within your own tenant.

This is a Microsoft API limitation, not a limitation of this MCP server. If Microsoft expands their API to support external networks in the future, this server can be updated to support them.

How It Works

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

Privacy: Every user registers their own Azure app and uses their own Microsoft credentials. No data ever goes through anyone else's infrastructure. Your login token is stored encrypted on your machine only.

Prerequisites

Node.js v18 or higher
Claude Desktop
A Microsoft work/school account with Viva Engage access

Step 1 — Register Your Own Azure App

This is a one-time setup (~10 minutes). You register your own app under your own Microsoft account. No one else can use your app — it is tied to your credentials only.

Go to portal.azure.com and sign in with your work/school Microsoft account
Search for "App registrations" → click "+ New registration"
Fill in:
- Name: mcp-viva-engage (or anything you like)
- Supported account types: Multiple Entra ID tenants → select Allow all tenants
- Redirect URI:
  - Platform = Public client/native (mobile & desktop)
  - URI = http://localhost
Click "Register"
On the overview page, copy and save both of these:
- Application (client) ID
- Directory (tenant) ID

Add API Permissions

In the left sidebar click "API permissions"
Click "+ Add a permission" → click the "All APIs" tab → search for "Yammer"
Click "Yammer" → click "Delegated permissions"
Check these four permissions:
- ✅ user_impersonation
- ✅ Community.Read.All
- ✅ EngagementConversation.ReadWrite.All
- ✅ Storyline.ReadWrite.All
Click "Add permissions"

Note for work/school accounts: Your organization's IT admin may need to grant consent for this app before you can log in for the first time. This is a one-time step. You can submit an approval request directly from the login screen when you first run the server.

Step 2 — Clone and Build

# 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

Step 3 — Configure Your Credentials

Copy the example env file:

# Windows
copy .env.example .env

# Mac/Linux
cp .env.example .env

Open .env and fill in your values from Step 1:

AZURE_CLIENT_ID=your-application-client-id-here
AZURE_TENANT_ID=your-directory-tenant-id-here

Important: Never commit your .env file to GitHub. It is already in .gitignore to prevent this.

Step 4 — Connect to Claude Desktop

Open your Claude Desktop config file:

Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

Add the viva-engage server to the mcpServers section:

{
  "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"
      }
    }
  }
}

Replace C:/path/to/mcp-viva-engage with the actual path where you cloned the repo. Windows paths can use forward slashes / or double backslashes \\.

Fully quit and restart Claude Desktop after saving.

The first time you ask Claude something about Viva Engage:

A browser window automatically opens with Microsoft's login page
Sign in with your work/school Microsoft account
Approve the permissions
Browser shows "Login successful!"
Claude completes your request

Your session is kept encrypted on your machine. When you restart Claude Desktop you may need to log in again.

Available Tools

Tool	Description
`get_networks`	Get all Viva Engage networks you belong to
`get_communities`	List all communities in your home network
`get_community_by_id`	Get details of a specific community by ID
`get_community_messages`	Get posts in a community — accepts name or ID, supports pagination
`get_recent_messages`	Get recent messages across all communities — great for daily summaries
`get_thread`	Get all messages in a conversation thread
`search_messages`	Search posts across your home network — supports date filtering
`post_message`	Post a new message to a community — accepts name or ID
`reply_to_message`	Reply to an existing conversation thread
`get_storyline_feed`	Get your personal Viva Engage storyline feed

Example Prompts

What you ask Claude	What happens behind the scenes
"Summarize what's new today"	`get_recent_messages` with `hours_ago: 24`
"What's new this week in ISV Collaboration?"	`get_community_messages` with name "ISV Collaboration"
"Find AL Extension posts this week"	`search_messages` with `from_date` set to 7 days ago
"Post to Developers group"	`post_message` with name "Developers" — no ID needed
"Summarize the last 10 posts in Business Central"	`get_community_messages` with name "Business Central"

Security & Privacy


🔐 Your own Azure app	Every user registers their own app — no shared infrastructure
🔐 Your own credentials	You log in with your own Microsoft account
🔐 Encrypted token storage	Token is encrypted using Windows DPAPI (or plain file on Mac/Linux)
🔐 No secrets in code	Client ID and Tenant ID stay in your local `.env` file only
🔐 Delegated permissions	Server can only see what you can already see in Viva Engage
🔐 Password never touched	Microsoft handles authentication entirely

Project Structure

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

Troubleshooting

"Approval required" on first login

Your organization requires admin consent for new apps. Ask your IT admin to approve the app in Azure portal → Enterprise Applications → find mcp-viva-engage → Grant admin consent. This is a one-time action.

Server not showing in Claude Desktop

Fully quit and restart Claude Desktop after editing the config file. Verify the path to dist/server.js is correct.

Login required again after restart

The encrypted token may have expired. Simply log in again — the session will be cached after login.

Only seeing home network communities

This is expected — see the Important Limitation section above. The Yammer REST API only supports home network access.

Path issues on Windows

Use either forward slashes C:/path/to/dist/server.js or double backslashes C:\\path\\to\\dist\\server.js in the config file.

get_recent_messages is slow

This tool scans all your communities one by one. If you have many communities it may take 10-20 seconds. This is normal — the Yammer API does not support bulk message fetching.

Known Limitations

Home network only — External networks (e.g. Microsoft BC Partners community) are not accessible via any public Microsoft API. See explanation above.
Rate limiting — Yammer API allows 10 requests per user per app per 30 seconds. get_recent_messages may hit this limit if you have many communities.
Read-only search — Search results are limited to what Viva Engage indexes.
No draft support — Messages posted via post_message are published immediately. There is no draft or preview mode in the Yammer API.

Roadmap

get_my_info — get current user profile for better context
like_message — like/unlike posts
get_community_members — list members of a community
Convert to a remote connector so users don't need local setup
Windows Credential Manager support for even more secure token storage
Support external networks if Microsoft adds API support in future

Changelog

v1.1.0

get_community_messages now accepts community name or ID (no more looking up IDs)
post_message now accepts community name or ID
search_messages now supports date filtering (from_date parameter)
New get_recent_messages tool — scan all communities for recent activity
Message bodies now return clean plain text (HTML tags stripped)
Pagination support added to get_community_messages

v1.0.0

Initial release

License

MIT — see LICENSE for details.

Disclaimer

This is an independent open source project and is not affiliated with, endorsed by, or supported by Microsoft or Viva Engage. Use at your own risk.

Available Tools

9 tools

get_communitiesGet CommunitiesA

Get all Viva Engage communities/groups the user is a member of in their home network

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_community_by_idGet Community By IDA

Get details of a specific Viva Engage community by its ID

ParametersJSON Schema

Name	Required	Description	Default
`group_id`	Yes	The ID of the community/group

TDQS

A3.5/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_community_messagesGet Community MessagesB

Get all messages/posts in a specific Viva Engage community in the home network

ParametersJSON Schema

Name	Required	Description	Default
`group_id`	Yes	The ID of the community/group

TDQS

B3.3/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_networksGet NetworksA

Get all Viva Engage networks the user belongs to

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_storyline_feedGet Storyline FeedA

Get the current user's Viva Engage storyline/personal feed

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_threadGet ThreadC

Get all messages in a specific conversation thread

ParametersJSON Schema

Name	Required	Description	Default
`thread_id`	Yes	The ID of the thread to retrieve

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_messagePost MessageC

Post a new message to a Viva Engage community

ParametersJSON Schema

Name	Required	Description	Default
`group_id`	Yes	The ID of the community to post to
`body`	Yes	The content of the message to post

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_messageReply To MessageB

Reply to an existing message or conversation thread

ParametersJSON Schema

Name	Required	Description	Default
`thread_id`	Yes	The ID of the message or thread to reply to
`body`	Yes	The content of the reply

TDQS

B3.3/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_messagesSearch MessagesA

Search for posts and messages across all communities in the home network

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search term or question to search for

TDQS

A3.5/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

platform7n
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
NetworkOS
com.thenetworkos
Your professional network in Claude — search contacts, log notes, and send warm intros.
CRM Note Taking
2
Fathom MCP Server
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
claude-context-bridge
io.github.PhoenixFeuer32
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Communication Knowledge & Memory Developer Tools
2

Related MCP Servers

Instagram DM MCP Server
Social Media Communication
addity3
A
license
Not graded
quality
Not graded
maintenance
Enables sending and receiving Instagram Direct Messages, managing conversations, downloading media, viewing user profiles and stories, and interacting with posts through natural language in Claude.
Updated 9 months ago (2025-12-09 03:02 UTC)
linkedin-mcp-server
Social Media Communication
greg0r1
A
license
A
quality
D
maintenance
Enables Claude Desktop to manage your LinkedIn profile and company pages, including posting, reading posts, and fetching profile information.
Updated 8 months ago (2026-01-10 11:46 UTC)
7
214
4
MIT
LinkedIn MCP Server
Social Media Communication
rgthelen
A
license
A
quality
D
maintenance
Enables Claude to interact with LinkedIn for posting, commenting, sharing media, and viewing feed and profile.
Updated a year ago (2025-08-15 20:21 UTC)
9
214
3
MIT
Office MCP Server
Email Calendar Management Communication
hvkshetry
A
license
Not graded
quality
B
maintenance
Connects Claude with Microsoft 365 services such as Email, Calendar, Teams, OneDrive, and more through the Microsoft Graph API.
Updated 19 days ago (2026-08-15 12:33 UTC)
60
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pranav4186/mcp-viva-engage'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-viva-engage

What You Can Do

Important Limitation — Home Network Only

How It Works

Prerequisites

Step 1 — Register Your Own Azure App

Add API Permissions

Step 2 — Clone and Build

Step 3 — Configure Your Credentials

Step 4 — Connect to Claude Desktop

Step 5 — First Login

Available Tools

Example Prompts

Security & Privacy

Project Structure

Troubleshooting

Known Limitations

Roadmap

Changelog

v1.1.0

v1.0.0

License

Disclaimer

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API