zaungast

by mbe24

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clear and distinct purpose: schema inspection, person resolution, conversation listing, message reading, full-text search, and topic extraction. No overlap in functionality.
Naming Consistency5/5
All tool names use consistent snake_case and follow a verb_noun pattern (describe_schema, find_person, list_conversations, read_messages, top_topics), with 'search' as a minor deviation but still common and predictable.
Tool Count5/5
6 tools is well-scoped for a Teams data access server, covering essential read and analysis operations without being overwhelming or sparse.
Completeness4/5
The tool set covers reading and analyzing local cache data comprehensively (schema, people, conversations, messages, search, topics). Minor gaps include lack of write operations and detailed conversation metadata retrieval, but this aligns with the stated read-only purpose.
Average 4.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 279 commits in the last 12 weeks
- Last stable release on July 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds important context by disclosing that it reads the local Teams cache and not the full server archive. However, it does not mention other behavioral traits like whether results are sorted or if pagination is supported.
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 two sentences plus a note, all essential. It is front-loaded with the core purpose and scoping, then adds a critical limitation. No wasted words.
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 moderate complexity (7 parameters, none required), the description adequately explains purpose, scoping, and the local cache limitation. It could be improved by mentioning the exemplar message structure but is sufficient for agent selection.
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 coverage is 100%, so the description adds limited meaning beyond the schema. It mentions 'window' and 'scope' conceptually but does not elaborate on format or edge cases for the parameters.
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 it returns distinctive/trending topics over a window, with scoping to overall, person, or conversation. It distinguishes from sibling tools like read_messages or search by focusing on trending analysis.
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 trending topics and mentions scoping, but lacks explicit guidance on when to use this tool vs alternatives like search or list_conversations. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that it reads the local Teams cache, not the full server archive, which is a critical behavioral trait. With no annotations provided, this disclosure adds value. It does not mention any destructive actions, which is consistent with a read operation.
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?
Two sentences cover purpose, filters, and a critical caveat. Every sentence is meaningful and efficient, front-loading the main function.
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?
The description lacks details about the return format or fields, which would help with no output schema. The caveat adds context, but overall completeness is moderate for a tool with 6 parameters.
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 coverage is 83%, so baseline is 3. The description lists filter options but does not add significant detail beyond the schema. It groups parameters but does not clarify formats or defaults beyond what the schema provides.
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 lists conversations with default newest N and filtering by kind/participant/title/time. The verb 'list' and resource 'conversations' are specific, and the tool is distinct from siblings like search or read_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing conversations with default and filter options. However, it does not explicitly state when not to use it or compare to alternatives, though sibling tools suggest different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it reads the local Teams cache, not the full server archive - a critical behavioral trait. No annotations provided, so this is valuable context.
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?
Three sentences with no redundancy: purpose, parameter hints, and behavioral note. Efficient and 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?
Covers purpose, key parameter usage, and the local cache limitation. Missing output details but acceptable given no output schema. Adequate for a search tool.
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?
With 50% schema description coverage, the description adds meaning for from/in and mentions_me, but leaves many parameters (since, until, kind, etc.) without additional explanation beyond the 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?
Clearly states 'full-text search across all messages with filters' and distinguishes from siblings like read_messages. The empty query behavior as filtered browse adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on empty query, from/in usage with substrings/handles, and mentions_me flag. Lacks explicit when-not-to-use vs siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: it 'inspects' (read-only) and 'proposes only — applies nothing', so no destructive action. Clear about its safe, non-modifying nature.
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?
Two sentences with clear front-loading of purpose. Efficient but could be slightly more concise (e.g., parentheses). Still very well structured.
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?
Tool has one optional parameter and no output schema. Description explains purpose, usage, and behavior adequately. Lacks mention of output format but sufficient for its simplicity.
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 only parameter 'limit' is fully described in the schema (100% coverage). The description adds no additional semantic info beyond the schema. Baseline 3 is appropriate.
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?
Clearly states it inspects raw IndexedDB stores and proposes a field mapping. Distinct from sibling tools which deal with people, conversations, messages, search, and topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: when schema is unrecognized after a Teams update or to inspect DB structure. Also clarifies it only proposes, not applies, and requires human verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses output fields (canonical name, p:handle, message count, last-contact time) and the scanning behavior ('most-talked-to first' when query omitted). It does not mention any destructive actions, which is appropriate. A slight improvement would be to confirm the tool is read-only.
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?
Three concise sentences: purpose, usage guidelines, and extra behavior. No redundancy. Efficiently front-loaded.
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?
Without annotations or output schema, the description covers input/output behavior but fails to explain the 'n' parameter. Since 'n' defaults to 8 and caps at 25, its role (number of results?) is not fully clarified. This gap reduces completeness.
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?
Schema coverage is 100% and descriptions in schema are decent. The tool description adds value by explaining the behavior of omitting query and the ordering. However, the 'n' parameter is not mentioned in the description, which could be overlooked.
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 resolves name fragments to canonical names and p:handles, with contact stats. It distinguishes from siblings by explicitly advising when to use search/read_messages instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (ambiguous name, need contact stats) and when not to (ordinary filtering, use search/read_messages). Provides alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behavior: it reads the local Teams cache only, not the full server archive, and explains the story order and pagination mechanisms. This provides complete transparency.
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?
Three sentences: first states purpose and order, second explains targeting and pagination, third notes the cache limitation. No unnecessary words, well-organized for quick comprehension.
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 7 parameters and no output schema, the description covers key behavioral aspects: targeting, pagination, ordering, and cache limitation. It could mention the limit default (in schema) or time filtering, but is sufficiently complete for a read tool.
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?
Schema coverage is 71% (some parameters lack descriptions like 'since' and 'until'). The description adds value beyond the schema by explaining targeting by handle/substring, pagination with cursor, and centering with around. It compensates for missing schema details but doesn't explicitly cover all parameters.
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 'Read' and the resource 'one conversation's messages'. It specifies the story order (oldest→newest) and how to target by handle or substring, distinguishing it from siblings like list_conversations or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: target by handle or substring, page back with cursor, center with around. It implies usage for reading a full conversation in order, but lacks explicit comparison to siblings like search or 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![zaungast MCP server](https://glama.ai/mcp/servers/mbe24/zaungast/badges/card.svg)](https://glama.ai/mcp/servers/mbe24/zaungast)

Score Badge

Copy to your README.md:

[![zaungast MCP server](https://glama.ai/mcp/servers/mbe24/zaungast/badges/score.svg)](https://glama.ai/mcp/servers/mbe24/zaungast)

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/mbe24/zaungast'

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