Claude AI를 Viva Engage(Yammer)에 연결하는 오픈 소스 MCP(Model Context Protocol) 서버입니다. 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)는 어떤 매개변수나 토큰을 사용하든 홈 네트워크의 데이터만 반환합니다. 외부 네트워크는 전체 웹 기반 로그인을 거친 후에만 사용할 수 있는 브라우저 세션 쿠키가 필요하며, 이는 API 호출만으로는 복제할 수 없습니다.
Microsoft의 최신 Graph API(graph.microsoft.com) 또한 외부 네트워크를 지원하지 않으며, 자체 테넌트 내의 네이티브 모드 네트워크에서만 작동합니다.
이는 이 MCP 서버의 제한이 아닌 Microsoft API의 제한입니다. 향후 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 (원하는 이름으로 설정 가능)
지원되는 계정 유형: Multiple Entra ID tenants → Allow all tenants 선택
리디렉션 URI:
플랫폼 = Public client/native (mobile & desktop)
URI = http://localhost
**"Register"(등록)**를 클릭합니다.
개요 페이지에서 다음 두 가지를 복사하여 저장합니다:
Application (client) ID (애플리케이션(클라이언트) ID)
Directory (tenant) ID (디렉터리(테넌트) ID)
왼쪽 사이드바에서 **"API permissions"(API 권한)**를 클릭합니다.
"+ Add a permission"(권한 추가) → "All APIs"(모든 API) 탭 → "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
mcpServers 섹션에 viva-engage 서버를 추가합니다:
{
"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첫 로그인 시 "승인 필요(Approval required)" 발생
조직에서 새 앱에 대해 관리자 승인을 요구하는 경우입니다. IT 관리자에게 Azure 포털 → Enterprise Applications →
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 BC Partners 커뮤니티)는 공개된 Microsoft API를 통해 액세스할 수 없습니다. 위 설명을 참조하십시오.
속도 제한 — 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
