Skip to main content

MCP discovery and block matching

GriMoire makes Microsoft 365 capabilities accessible through natural conversation within the SharePoint page. The assistant discovers tools at runtime, executes them, and maps results into typed UI blocks that fit the visible workspace.

User intent
→
Resolve capability
Agent 365 or MCP server
→
Execute tool
Backend MCP proxy
→
Parse result
Schema inference
→
Typed UI block
Actionable, interactive
→
HIE tracks block
Grounded interaction

The problem it solves​

MCP tools can return many different data shapes:

  • a single object
  • a list of items
  • an action result
  • markdown-like structured text
  • payloads that look like mail, calendar, files, lists, or users

If you render all of that as plain assistant text, you lose:

  • structure
  • clickability
  • stateful follow-up
  • visual grounding

GriMoire's approach​

At a high level, the system does five things:

  1. resolve which server and tool should be used
  2. derive the target context — which site, library, file, mail item, or Teams channel the tool should operate on
  3. execute the tool through the backend MCP proxy
  4. infer what kind of result came back
  5. map that result into a typed UI block whenever possible

This maps tool output into the block-based UI rather than raw text.

Target context resolution​

One of the hardest problems in tool execution is knowing what to target. When the user says "open that document", the system needs to resolve which document, on which site, in which library.

The execution layer coordinates this by deriving target context from multiple sources:

  • HIE source context — if the user selected or interacted with a block, the adapter extracts the relevant identifiers (site URL, list ID, item ID, mail item ID, etc.)
  • Current page context — the SharePoint page the user is on provides a default site and web
  • Explicit user input — when the user provides a URL or name directly

These sources are merged with field precedence into a unified target context that the MCP tool receives as arguments. This is what makes follow-up actions like "share that file" work without the user re-specifying which file they mean.

Built-in capability surface​

GriMoire ships with a built-in Microsoft 365 capability surface for Agent 365-backed servers:

  • SharePoint and OneDrive
  • SharePoint Lists
  • Outlook Mail
  • Outlook Calendar
  • Teams
  • User profile
  • Copilot Search
  • Word

These tools produce results that are rendered as interactive blocks and support follow-up actions.

Schema inference​

Some tool responses are obvious, and some are not.

GriMoire therefore uses shape-based inference to answer questions like:

  • does this payload look like a user card?
  • does this look like a list of search results?
  • is this a file preview?
  • is this an action result that should become an info card instead?

This matters because it lets the system move from generic tool execution to typed block rendering.

Generic block building​

Once the result shape is inferred, a generic block builder can construct the corresponding UI block data instead of forcing every tool to own a custom renderer.

That is an important design decision because it scales better than hard-wiring every single tool to a bespoke UI path.

Why this matters for users​

The user benefit is simple:

  • tool results become readable
  • result items become selectable
  • follow-up becomes easier
  • UI state becomes available to the HIE

So the MCP layer is not just about extensibility. It is also about making action output fit the UI language of GriMoire.