WinMCP Server

by collero

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource/action combination: search, get-by-ID, lookup-by-key, and write operations are clearly separated across calendar, mail, tasks, files, and OneNote. Even close pairs like calendar_search and calendar_get_notes are distinguishable by their lookup key and return shape.
Naming Consistency4/5
Tool names consistently use a lowercase snake_case {resource}_{action}[_target] pattern, which is predictable and readable. The only mild deviations are server_info, which is not action-based, and calendar_get_notes, which uses 'notes' rather than an event/appointment term.
Tool Count5/5
Fifteen tools is at the upper end of the ideal range but appropriate given the five subdomains covered: calendar, tasks, mail, files, and OneNote, plus a server_info utility. No tool feels redundant; each adds a distinct search, read, or write capability.
Completeness3/5
The read/search surface is strong across all domains, and OneNote additionally supports create and update operations. However, calendar, task, and mail tools are read-only, file content is not retrievable, and there are no delete operations anywhere, leaving notable lifecycle gaps for a general Windows/Outlook automation server.
Average 4.4/5 across 15 of 15 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It clearly indicates a read operation that returns subject and body, but it does not describe behavior when no match is found, when multiple matches exist, or whether matching is exact.
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 front-loaded sentence with no filler. Every phrase adds useful information: the operation, the lookup keys, and the return contents.
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 two-parameter lookup with an output schema present, the description covers the core calling contract. However, it does not disambiguate this tool from closely related siblings like calendar_get_event or calendar_search, and it omits edge-case behavior that an agent might need to know before invoking it.
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?
With 0% schema description coverage, the description compensates by explaining both parameters as the matching criteria ('date+subject') and identifying the output fields ('subject + body'). It adds real meaning beyond the raw schema, though it stops short of defining exact-match semantics or date-normalization behavior.
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 states a specific operation—resolving a single note-appointment by date and subject—and mentions what is returned ('full detail (subject + body)'). It is clear enough to be useful, though the compound term 'note-appointment' is unusual and the description does not explicitly distinguish this from calendar_get_event.
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 phrase 'matching date+subject' implies this tool is for retrieving a specific existing note-appointment when both lookup values are known. However, it does not explicitly state when to prefer this over siblings like calendar_search or calendar_get_event, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does reveal the read-only nature ('Fetch') and the fact that the body is included, which is useful. However, it does not describe error behavior, missing events, authentication requirements, or response shape beyond what an output schema might imply.
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, compact sentence that front-loads the core action and key parameter with no filler. Every word contributes value.
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 one-parameter retrieval tool with an output schema present, the description covers the essential behavior and parameter semantics. It does not explicitly mention when to use the tool relative to siblings, but that gap is already separately accounted for in usage guidelines.
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 description coverage is 0%, so the description must compensate. It adds meaningful context by explaining that the entryId is an Outlook entryId and that it identifies a single event. This is more informative than the bare string type in the schema, though it could specify where to obtain the entryId.
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 a specific verb ('Fetch'), resource ('single event'), scope ('full detail including body'), and the lookup key ('Outlook entryId'). This distinguishes it from sibling tools like calendar_search and calendar_get_notes without ambiguity.
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 usage context is implied: use this when you need full event details by a single Outlook entryId. However, it does not explicitly state when to prefer this over calendar_search or other siblings, nor does it mention any exclusions or alternatives.
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?
With no annotations provided, the description carries the full behavioral burden. It discloses the default folder scope, the effect of a filterless call, the limit default (50), the hard maximum (200), clamping behavior for over-max values, and rejection of <= 0. This is substantive transparency beyond a simple 'search tasks' line, though it omits minor details like sort order or date boundary inclusivity.
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 with no wasted words. The first sentence states the purpose immediately, and the second packs the essential filter and limit behavior efficiently. Front-loading is excellent.
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 output schema exists, so return values are covered, and the limit behavior is well documented. However, with six optional parameters, no annotations, and zero schema descriptions, the tool still lacks needed clarity on filter semantics for most parameters. It is usable but has clear gaps that an agent would have to resolve through inference or experimentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the `limit` parameter in detail. The other five parameters (`dueTo`, `dueFrom`, `status`, `subject`, `includeNoDueDate`) are left to name-based inference, with no explanation of matching semantics, range inclusivity, or defaults beyond what the parameter names imply. This is insufficient for confident invocation.
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 names a specific verb ('Search') and a specific resource ('default Outlook Tasks folder'), making the tool's purpose unmistakable. It implicitly distinguishes itself from sibling search tools for mail, calendar, OneNote, and files, and from task_get_task by emphasizing folder-wide search rather than single-task retrieval.
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 gives clear context: this is the tool for searching the default Outlook Tasks folder, and filters are optional with filterless returning all tasks. It does not explicitly name alternatives or exclusion conditions, so it falls short of a 5, but the usage context is strong enough for an agent to select it appropriately.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important operational traits: the filename search is case-insensitive and uses a bounded filesystem walk independent of the Windows Search index, while phrase search uses ADO with a PowerShell fallback. It also discloses the resultsTruncated flag, though it does not cover potential errors, permissions, or latency.
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?
The description is dense but every clause earns its place, covering search modes, backend mechanisms, constraints, and output flags. It is front-loaded with the core action and keeps technical details in parentheticals. It is slightly long due to implementation detail, but it is not redundant.
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 there are no annotations and the output schema exists, the description sufficiently covers call requirements, parameter constraints, and return behavior via the resultsTruncated flag. It would benefit from explicit examples of filename/phrase formatting and a direct note about when to prefer this tool over sibling searches, but nothing critical is missing for invoking it correctly.
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 description coverage is 0%, so the description must compensate for the bare schema. It does this effectively by assigning semantics to all three parameters: filename as a substring, phrase as a full-text match, and scope as an absolute subtree. It also clarifies the mutual-exclusion-like constraint that at least one of filename/phrase must be provided and that scope is restricted to allowed roots.
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 states a precise operation: search files by a case-insensitive filename substring and/or a full-text phrase, optionally within an absolute scope subtree. It names the specific resource and mechanism, and clearly distinguishes itself from sibling search tools by focusing on files. Even without naming siblings, the scope and technical detail remove ambiguity.
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 provides clear invocation constraints: at least one of filename/phrase is required and scope must be within an allowed root. However, it never explicitly states when to use this tool over alternatives such as file_get_info, mail_search, or onenote_search, nor does it describe when not to use it. Usage is implied by the resource type, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It communicates the path format, the search-root restriction, and that the operation is a metadata fetch, implying read-only behavior. However, it does not disclose error behavior, permission requirements, or what happens when the path is invalid or outside the allowed root.
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 with no filler. The core purpose and resource are front-loaded, followed by essential path-format and restriction details. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple single-parameter metadata retrieval tool with an output schema present, the description covers the necessary invocation details: what the tool does, acceptable path forms, and a security constraint. Nothing critical is missing for selecting and calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining the single parameter 'path' with concrete format guidance: native path or file:/// URL, as returned by file_search, and constrained to an allowed root. This adds substantial meaning beyond the bare string type in 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?
The description explicitly states a specific action ('Fetch full indexed metadata'), a specific resource type ('a single file'), and the accepted path forms. It distinguishes itself from file_search by describing the post-search retrieval use case, making its role clear among siblings.
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 provides clear usage context by indicating that paths come from prior file_search results and must be within an allowed search root. It does not explicitly state when not to use the tool or name alternatives, but the workflow implication is strong and sufficient for an agent.
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?
With no annotations, the description carries the full burden and does so well: it discloses limit semantics (default 50, hard max 200, over-max clamped not rejected, <= 0 rejected) and how folderPath resolves from the default mail store's root. It stops short of full transparency — result ordering, error behavior for a nonexistent folderPath, and explicit read-only/auth status are unstated.
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?
The description is dense but front-loaded: the core purpose leads, and every clause about folders, filters, and limit earns its place with zero filler. The heavy parentheticals and em-dash chains make it harder to scan than a structured list, but nothing is redundant or wasted.
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 nullable parameters with interdependent constraints and an output schema that documents return values, the description gives an agent everything needed for a correct first call: the XOR folder rule, the at-least-one filter rule, and clamping semantics. Remaining gaps — invalid-folderPath error behavior and result ordering — are minor for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it covers every parameter: folder vs folderPath mutual-exclusivity semantics, '/' delimited path meaning, substring semantics for subject/sender, date-range meaning for dateFrom/dateTo, and the limit clamp/reject behavior. This vastly exceeds what the bare 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 opens with 'Search the default Outlook Inbox, Sent Items, or Drafts folder' — a specific verb (Search), a concrete resource (Outlook mail folders), and a defined scope (folder/folderPath selection plus filters). This clearly distinguishes it from sibling search tools targeting calendar, tasks, files, and OneNote, and from mail_get_message by the search-vs-fetch semantics.
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?
It gives clear invocation context: 'exactly one of folder/folderPath is required' and 'at least one of dateFrom/dateTo/subject/sender is required,' which tells an agent precisely when the tool is appropriate and what it needs. However, it never names a sibling alternative (e.g., mail_get_message for single-message retrieval), so there is no explicit when-not or exclusion guidance.
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 provided, the description carries the full burden and does so well. It discloses that bodyText is written as a single plain-text paragraph, that the owning notebook is checked against an allowlist before any write, and that refusal produces a specific [onenote_notebook_not_allowed] error. This is meaningful behavioral context.
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 compact and front-loaded, with the core action in the first clause. Every sentence carries useful operational detail: canonical format, source of valid IDs, bodyText behavior, allowlist check, and error outcome. There is no padding.
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 write action with no annotations, the description is unusually complete: it covers input sources, format constraints, a security precondition, and error behavior. The main missing piece is the semantics of the required title parameter, which keeps it from a 5.
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 0%, so the description must compensate. It adds strong semantics for sectionId (canonical form, source, non-resolving alternatives) and bodyText (plain-text paragraph), but the required title parameter is never described. This is a clear gap for a required argument.
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 opens with a specific verb and resource: 'Create a new page in the OneNote section identified by sectionId.' This clearly differentiates the tool from siblings like onenote_get_page and onenote_update_page, even without explicitly naming them.
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 gives clear context: it is for creating a page, and it tells the agent to obtain sectionId from onenote_list_sections or onenote_search rows. It does not explicitly state when not to use this tool or mention onenote_update_page as an alternative, so it stops short of a 5.
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?
With no annotations, the description carries the behavioral burden. 'Fetch' clearly signals a non-mutating read operation, and 'including body' adds useful behavior beyond a simple metadata lookup. It does not mention error or authorization cases, but these are not critical for a simple get-by-id tool.
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, efficient sentence with no redundant words. The core action and identifier type are front-loaded, and every word earns its place.
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 a one-parameter tool with no parameter descriptions, an existing output schema, and a clear explanatory description, the definition is nearly complete. It might benefit from pointing to task_search for discovering entryIds, but the essential information for correct invocation is present.
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?
The schema provides only a bare string property with no description. The tool description compensates by identifying the parameter as an 'Outlook entryId', giving the agent the key semantic needed to invoke the tool correctly. It could add format or example details, but this is adequate for a single required parameter.
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 uses a specific verb ('Fetch'), names the resource ('a single task'), and states the scope ('by its Outlook entryId'). It also adds distinctive detail ('including body') that separates it from sibling tools like task_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 makes clear it is for fetching one known task via an entryId, which implies the appropriate context: use it after you have an entryId and need full details. It does not explicitly name alternatives or exclusion conditions, but the intent is unambiguous.
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?
No annotations are provided, so the description carries the full burden. It discloses conditional response behavior: attachmentNames is always populated while htmlBody is only populated when includeHtmlBody=true (default false). It could add error/not-found behavior but covers the key conditional.
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 compact sentences. The first gives purpose and scope; the second gives the field-availability nuance. No filler or repetition.
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 two-parameter retrieval tool with an output schema, the description covers the call shape, parameter effect, and important field-population behavior. It could mention what happens when the entryId is not found, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: entryId is identified as the Outlook message identifier, and includeHtmlBody is explained with its effect on htmlBody population and its default. Both parameters are given meaningful semantics beyond the bare 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?
States a specific action ('Fetch full detail ... for a single ... message by its Outlook entryId'), clearly distinguishing it from search or listing tools. The mention of Inbox/Sent Items/Drafts/folderPath adds scope.
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 makes the use case explicit: use when you have an Outlook entryId and need the full single message, including body and attachments. It does not explicitly name sibling alternatives such as mail_search, so it stops short of a 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only; never mutates any state,' which is important and accurate. It also clarifies the exact identifier format returned. Since this is a simple zero-parameter listing tool, this level of transparency is adequate, though it does not discuss pagination or size 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?
The description is two sentences with no fluff. The first sentence states the core purpose, and the second adds the crucial canonical-id detail and safety guarantee. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing operation with an output schema, the description covers everything an agent needs: what the tool returns, why the format matters, the tool it feeds, and the non-mutating guarantee. No missing context blocks correct invocation.
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?
The tool has zero parameters, so there is nothing to document beyond the schema. The description adds useful meaning about what the returned output contains—canonical ids for every notebook/section pair—and emphasizes the critical id format. This matches the baseline for a no-parameter tool.
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 states a specific verb and resource: 'List every OneNote notebook/section pair with its canonical ids.' It also clearly distinguishes the tool's output by emphasizing the `{GUID}{1}{B0}` sectionId form required by `onenote_create_page`, setting it apart from searching or fetching page content.
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 gives actionable context by explaining that this tool yields the canonical sectionId needed by `onenote_create_page`, and warns that a bare GUID or section name will never resolve. It does not explicitly tell when not to use it or name alternatives like `onenote_search`, but the routing information is clear enough for the primary use case.
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 provided, the description carries the full behavioral burden, and it delivers thoroughly. It discloses read-only semantics, explains that `bodyText` is a flattened reading view rather than storage format, clarifies what `bodyTextIncomplete: true` means, and details the conflict-guard contract around `lastModifiedDateTime`. This is exemplary transparency for a fetch 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?
The description opens with the core purpose and read-only guarantee, then front-loads the key parameter relationship. The subsequent caveats about flattened text, incomplete content, and the update conflict guard are dense but each earns its place because they prevent realistic misuse. The length is justified and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description covers the essential semantics: what the output fields mean, what incompleteness signals, and how the result interacts with the sibling update tool. Error cases and authorization are not mentioned, but the behavioral and integration context provided is sufficient for correct invocation.
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?
The input schema only defines `pageId` as a required string with no description, so the description must compensate. It does so by stating that `pageId` is the value returned by `onenote_search` and is used to address a single page. This adds useful source-level meaning beyond the raw schema, though it does not elaborate on format or validation.
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 states a specific action ('Fetch full, read-only text detail') on a specific resource ('a single OneNote page') and identifies the exact identifier needed (`pageId`). It also explicitly declares that the operation never mutates state, which distinguishes it from write tools like `onenote_create_page` and `onenote_update_page`.
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 clearly ties `pageId` to the output of `onenote_search`, signaling where the identifier comes from, and explains how `lastModifiedDateTime` should be passed back to `onenote_update_page`. It does not explicitly state 'use this instead of X' or provide when-not-to-use guidance, but the context strongly implies the intended workflow among the sibling 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 carries the behavioral burden. It explicitly states 'Read-only, touches no Outlook/OneNote/file state,' discloses the edge case for source checkouts/pre-stamp packages (null with a note), and explains the deployment verification behavior. This is unusually 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?
The description is information-dense without fluff: each sentence contributes a distinct piece of value—output contents, edge-case handling, safety guarantee, and a concrete usage recommendation. It is front-loaded with the core purpose and maintains clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introspection tool, the description is complete: it covers what data is returned, when to call it, why ordering matters, and side-effect guarantees. The presence of an output schema further reduces the need to describe return structure in prose.
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?
The tool has zero parameters, so there is nothing for the description to add beyond the empty input schema, which is fully covered. The baseline of 4 applies because no parameter documentation is needed; the description focuses on outputs and behavior instead.
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's purpose: 'Identify this deployment' and enumerates specific outputs such as package name, build UTC/build id, install root, Python version, and registered tool names. This distinguishes it from sibling data-access tools (calendar, mail, files, OneDrive, tasks) by focusing on server/build introspection rather than domain content.
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 gives explicit usage guidance: 'Call it FIRST when verifying that a redeployed build is the one answering' and explains the stale-server scenario. It does not name specific sibling alternatives or provide when-not-to-use conditions, but the read-only, no-state statement implies it is not for Outlook/OneNote/file operations.
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 provided, the description carries the full burden, and it delivers: it discloses the default 90/365-day window, configuration via lookback/lookahead settings, the windowApplied echo, override semantics, and limit clamping/rejection behavior. This is unusually transparent about side effects and edge cases.
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 dense but every sentence carries information an agent needs: purpose, requirement, default-window behavior, override semantics, and limit rules. It is well-structured, front-loading the core operation before explaining edge-case behavior, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, zero required, no annotations, and non-trivial default-window logic, the description covers all important behavioral aspects. It also explains the configurable nature and response echo (windowApplied) without needing to describe the output schema since one exists. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, and it does. It defines from/to as an explicit date range, subject as a substring, and limit with default 50, hard max 200, clamping vs rejection of over-max, and rejection of <=0. Every parameter receives meaningful semantic detail beyond the raw 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?
The description clearly states the verb 'Search' and the specific resource 'the default Outlook calendar folder', and it specifies the two search dimensions (date range and subject substring). It is distinguishable from siblings like calendar_get_event and calendar_get_notes, which imply retrieving specific items rather than searching across a folder.
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 gives strong usage context: at least one of from/to/subject is required, explains subject-only search window behavior, and describes how explicit from/to overrides the window. It does not explicitly name alternative tools or say 'use X instead', but the usage conditions are clear enough for an agent to decide when this search tool is appropriate.
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 carries the full behavioral burden and does so thoroughly: it documents `[invalid_request]` validation, the default and hard maximum for `limit`, clamping behavior for over-max values, rejection of `<= 0`, and empty-result semantics (`[]`, not an error). This gives an agent concrete expectations before calling.
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 dense but compact, front-loading the core purpose and then providing only high-value behavioral details. Every sentence earns its place, with no repetition of the tool name or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with an output schema present, the description is complete: it covers required input, validation errors, default and boundary behavior, and the empty-result case. Even without annotations, it fully prepares an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by fully explaining both parameters: `query` must be non-empty, and `limit` is optional with default 50, hard max 200, clamping over-max, and rejection of invalid values. This adds meaning far beyond the raw 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?
The description states a specific action: 'Full-text search over OneNote page content' and identifies the underlying implementation via `FindPages`. This clearly distinguishes it from siblings like onenote_get_page and onenote_list_sections, so an agent understands the tool's unique purpose.
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 gives clear context: this is for full-text content search, not listing sections or fetching a specific page. It does not explicitly name alternative tools or exclusion conditions, but the search-focused framing is sufficient to guide selection among the OneNote siblings.
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 provided, the description fully carries the behavioral disclosure burden. It explains the append-only guarantee, preservation of original formatting, the conflict guard mechanism, the exact error raised on mismatch, the unguarded overwrite escape hatch, and the notebook allowlist check. This is exceptional 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?
The description is longer than average, but every sentence adds essential operational detail. It front-loads the core behavior first, then explains the conflict guard, then the allowlist context. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, three parameters, and complete absence of annotations or schema descriptions, the description covers everything an agent needs: what the tool does, how each parameter behaves, failure modes, retry guidance, and permissions context. The output schema exists, so not detailing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, and it does. bodyText is defined as a plain-text paragraph, pageId is the page target, and dateExpectedLastModified gets a detailed explanation of its role as a conflict guard, including how to obtain it, when to omit it, and what happens on mismatch.
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 opens with a specific verb and resource: 'APPEND bodyText as one new plain-text paragraph at the end of the OneNote page.' It also explicitly distinguishes the behavior from replacing or reformatting content, which separates it from related page tools like onenote_create_page.
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 gives clear practical context: when to use, how to handle conflict-guard values, and when to omit the guard for an unguarded overwrite. It references onenote_get_page and onenote_create_page for related behavior, but it does not explicitly state exclusions such as 'create a new page instead' or 'use search instead.'
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:

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

Score Badge

Copy to your README.md:

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

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/collero/winMCP'

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