Skip to main content
Glama
littlebearapps

Outlook Assistant

by littlebearapps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Contacts

manage-contact
Destructive

List, search, retrieve, create, update, or delete personal Outlook contacts; preview deletions with dryRun before permanent removal.

Instructions

Full CRUD over the signed-in user's personal Outlook contacts (destructive: covers delete action). action=list (default) returns contacts with pagination via skip/count (default 50). action=search returns contacts matching query against name/email (default 25). action=get returns full contact detail by id. action=create adds a new contact and returns its id. action=update patches the given fields by id (only fields passed are changed). action=delete removes the contact by id; it skips Deleted Items, so treat it as permanent and pass dryRun: true first to confirm which contact it is. Use outputVerbosity (minimal/standard/full) on list/search to control field count. Searches only your personal contact store; for relevance-ranked search across contacts, the directory and recent communications, use search-people.

Input Schema

NameRequiredDescriptionDefault
idNoContact ID (action=get/update/delete, required)
skipNoPagination offset for action=list (default: 0). Use the value suggested by the previous page response.
countNoNumber of results (action=list default: 50, action=search default: 25)
emailNoPrimary email address (action=create/update)
notesNoPersonal notes (action=create/update)
queryNoSearch query for name or email (action=search, required)
actionNoAction to perform (default: list)
dryRunNoPreview only (action=delete): nothing is deleted. Shows which contact would be removed. Other actions refuse dryRun and change nothing. Default false.
emailsNoMultiple email addresses (action=create/update). First entry is primary.
folderNoContact folder ID (action=list)
jobTitleNoJob title (action=create/update)
lastNameNoSurname (action=create/update). Maps to Graph `surname`.
firstNameNoGiven name (action=create/update). Maps to Graph `givenName`. If displayName not provided, will be combined with lastName.
companyNameNoCompany name (action=create/update)
displayNameNoFull name (action=create/update)
mobilePhoneNoMobile phone number (action=create/update)
outputVerbosityNoOutput detail level (action=list/search, default: standard)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.14.1
    • addedInput schema / properties / dryRun
      Added value: +{
+  "description": "Preview only (action=delete): nothing is deleted. Shows which contact would be removed. Other actions refuse dryRun and change nothing. Default false.",
+  "type": "boolean"
+}
  2. Addedv3.9.1
  3. Removedv3.9.0
  4. Changed5 schema fields changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / emails
      Added value: +{
+  "description": "Multiple email addresses (action=create/update). First entry is primary.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / firstName
      Added value: +{
+  "description": "Given name (action=create/update). Maps to Graph `givenName`. If displayName not provided, will be combined with lastName.",
+  "type": "string"
+}
    • addedInput schema / properties / lastName
      Added value: +{
+  "description": "Surname (action=create/update). Maps to Graph `surname`.",
+  "type": "string"
+}
    • addedInput schema / properties / skip
      Added value: +{
+  "description": "Pagination offset for action=list (default: 0). Use the value suggested by the previous page response.",
+  "type": "integer"
+}
  5. First observedv3.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: delete skips Deleted Items so it is irreversible, dryRun is only honored on delete (other actions refuse it and change nothing), update patches only the fields passed, and pagination defaults differ per action (50 list / 25 search). The annotations only carry destructiveHint=true and readOnlyHint=false; the description supplies the operational consequences.

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?

Front-loads scope and the destructive warning, then walks actions in a consistent pattern with no filler sentences. It is dense but slightly long, with pagination and verbosity details that are partly duplicated by the schema descriptions.

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 17-parameter, action-dispatch CRUD tool with no output schema, the description covers every action, defaults, side effects, safety workflow, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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%, so the baseline is 3, but the description adds real meaning: `outputVerbosity` values control returned field count, `skip` should echo the previous page's suggested value, `id` scoping across get/update/delete, and update's patch-only semantics. It largely restates defaults already in the schema, which caps it below 5.

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 verb (full CRUD) plus the exact resource (signed-in user's personal Outlook contacts) and enumerates every action with its effect. It also distinguishes itself from the sibling `search-people` by scope (personal store only), so an agent can pick between them without opening a schema.

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?

Gives explicit per-action routing (list/search/get/create/update/delete), names the required inputs for each, and states the alternative for ranked cross-source search (`search-people`). It also prescribes a workflow: pass `dryRun: true` before a permanent delete to confirm the target contact.

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

Deploy Server

Other Tools