Conecto

Connect Microsoft 365

m365_connect

Connect the company's own Microsoft 365 so the agent works in its Outlook mail, calendars and OneDrive files, which stay the source of truth. The company registers an app in Microsoft Entra ID with the application permissions Mail.ReadWrite, Mail.Send, Calendars.ReadWrite and Files.ReadWrite.All, and its admin consents. Give its tenant_id and client_id, and the mailboxes the agent may act as (it never acts as anyone else). Called without secret, it answers with a link for the owner, who types the client secret on a Conecto page, so it never passes through the chat (from_a_terminal does the same from a terminal); account.credential_added says when it is connected. Each mailbox is checked before anything is kept. On accounts with an owner, cancelling events and replacing files wait for the owner's approval by default. Free. Free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tenant_id": "<tenant_id>",
      "client_id": "<client_id>",
      "mailboxes": "<mailboxes>"
    },
    "name": "m365_connect"
  }
}

Input Schema

Name	Required	Description
`secret`	No	The app's client secret. Never shown again. Leave it out to get the link instead.
`client_id`	Yes
`mailboxes`	Yes	The addresses the agent may act as, like support@ and sales@.
`tenant_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / secret / description

Previous value: -"The app's client secret. Never shown again."New value: +"The app's client secret. Never shown again. Leave it out to get the link instead."

changedInput schema / required

Previous value: -[
-  "tenant_id",
-  "client_id",
-  "secret",
-  "mailboxes"
-]New value: +[
+  "tenant_id",
+  "client_id",
+  "mailboxes"
+]

First observedOct 28, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Far beyond the annotations, it discloses the invite-link secret flow that keeps the client secret out of chat, the owner-approval gate on cancelling events and replacing files, per-mailbox verification before anything is kept, and the account.credential_added signal for completion. It is consistent with readOnlyHint=false and destructiveHint=false, and the mailbox scoping ('never acts as anyone else') is the kind of detail annotations cannot carry.

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?

Purpose is front-loaded and most clauses earn their place, but the body is one long run-on sentence with the parenthetical detour, and the description ends with a literal duplicated 'Free. Free.' — a visible defect that wastes space.

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?

With no output schema, the description usefully explains what comes back (a link for the owner) and how completion is signalled (account.credential_added). The remaining gap is re-invocation semantics: idempotentHint=false but nothing says whether calling again replaces the mailbox list, rotates credentials, or errors.

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 only 50%, so the description must compensate for the undocumented tenant_id and client_id — which it does by framing them as the company's Entra ID tenant and registered app identifier, and by explaining that mailboxes are the addresses the agent may act as. It doesn't give formats or limits (e.g. up to 20 mailboxes, which is only inferable from the schema), so it stops short of a perfect score.

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 opening sentence gives a specific verb and resource ('Connect the company's own Microsoft 365') plus the exact scope it unlocks (Outlook mail, calendars, OneDrive). It clearly distinguishes itself from m365_disconnect and the parallel google_connect/outreach_connect_mailbox style siblings by naming the provider and the acting-as-mailboxes constraint.

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 states concrete preconditions — an Entra ID app registration with Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, Files.ReadWrite.All and admin consent — plus which three inputs to supply. It also routes between the two call modes (with secret vs. without secret, deferring to from_a_terminal for terminal use), but never names an alternative sibling tool or an exclusion case for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Conecto tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?