Andru

Prepare for a meeting

get_pre_brief

Prepare for an upcoming meeting or call by generating a short brief on what each attendee likely wants, the concerns they need answered, and where they'll disagree.

Instructions

Use this when the person has a specific upcoming meeting or call and wants to be ready for it. This is the default for "prepare me for my call". Returns a short brief: what the meeting is for and what each person in the room likely thinks going in (what they want, the concerns they need answered, what moves them, and where they'll disagree), built from the account's buying committee and labelled as Andru's assumptions to correct. Send the meeting (from their calendar, or described in a sentence), what kind of meeting it is, and who will be there by title. If you leave out who's in the room, Andru answers with the six buyers to choose from. To talk with the buyers before the meeting, use simulate_buyer_persona with the same brief.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_pre_brief"
  }
}

Input Schema

Name	Required	Description
`room`	No	Who will be there: up to 8 people, each with their title and, if you know it, which of the six buyers they are.
`stage`	No	Where the deal is, by the last thing the buyer did (required for a deal meeting).
`meeting`	No	The meeting in a sentence if it isn't on their calendar, e.g. 'pricing call with the company's VP of Finance and their IT lead'.
`meetingId`	No	The meeting from the person's calendar (an id from a previous reply). Leave it out and describe the meeting in `meeting` instead.
`situation`	No	What kind of meeting: a discovery call, where they speak first; a deal meeting (demo, pricing, pilot, procurement); or a customer review.
`companyName`	No	Company you're meeting. Andru looks for the matching meeting on the person's calendar.

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv1.4.10Oct 26, 2026

removedInput schema / properties / briefType

Removed value: -{
-  "description": "Type of meeting brief to generate (default: general)",
-  "enum": [
-    "general",
-    "discovery",
-    "demo",
-    "negotiation",
-    "renewal",
-    "expansion"
-  ],
-  "type": "string"
-}

changedInput schema / properties / companyName / description

Previous value: -"Company you're meeting with. Andru finds the matching calendar event and pulls attendee context automatically."New value: +"Company you're meeting. Andru looks for the matching meeting on the person's calendar."

removedInput schema / properties / contactName

Removed value: -{
-  "description": "Name of the person you're meeting (optional — helps match the right event and personalize the brief).",
-  "type": "string"
-}

removedInput schema / properties / dealId

Removed value: -{
-  "description": "Associated deal ID for additional deal intelligence",
-  "type": "string"
-}

removedInput schema / properties / eventId

Removed value: -{
-  "description": "Calendar event ID (from Andru calendar integration). If provided, skips calendar search.",
-  "type": "string"
-}

removedInput schema / properties / idempotencyKey

Removed value: -{
-  "description": "Optional: any unique string for this call. Retrying with the same key returns the first result and never charges twice.",
-  "type": "string"
-}

removedInput schema / properties / maxAmountCents

Removed value: -{
-  "description": "Optional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.",
-  "minimum": 0,
-  "type": "integer"
-}

addedInput schema / properties / meeting

Added value: +{
+  "description": "The meeting in a sentence if it isn't on their calendar, e.g. 'pricing call with the company's VP of Finance and their IT lead'.",
+  "type": "string"
+}

addedInput schema / properties / meetingId

Added value: +{
+  "description": "The meeting from the person's calendar (an id from a previous reply). Leave it out and describe the meeting in `meeting` instead.",
+  "type": "string"
+}

removedInput schema / properties / quoteId

Removed value: -{
-  "description": "Optional: the quote_id from quote, to pay the quoted price (held for 30 minutes).",
-  "type": "string"
-}

addedInput schema / properties / room

Added value: +{
+  "description": "Who will be there: up to 8 people, each with their title and, if you know it, which of the six buyers they are.",
+  "items": {
+    "properties": {
+      "buyerKey": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "title"
+    ],
+    "type": "object"
+  },
+  "maxItems": 8,
+  "type": "array"
+}

addedInput schema / properties / situation

Added value: +{
+  "description": "What kind of meeting: a discovery call, where they speak first; a deal meeting (demo, pricing, pilot, procurement); or a customer review.",
+  "enum": [
+    "discovery",
+    "deal",
+    "customer_review"
+  ],
+  "type": "string"
+}

addedInput schema / properties / stage

Added value: +{
+  "description": "Where the deal is, by the last thing the buyer did (required for a deal meeting).",
+  "maximum": 7,
+  "minimum": 0,
+  "type": "integer"
+}

Changed3 schema fields changedv1.4.9Oct 24, 2026

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Optional: any unique string for this call. Retrying with the same key returns the first result and never charges twice.",
+  "type": "string"
+}

addedInput schema / properties / maxAmountCents

Added value: +{
+  "description": "Optional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / quoteId

Added value: +{
+  "description": "Optional: the quote_id from quote, to pay the quoted price (held for 30 minutes).",
+  "type": "string"
+}

First observedv1.4.0Mar 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds real context beyond the annotations: the output is explicitly labelled as Andru's assumptions to correct, and there is a documented fallback (leave out the room and Andru replies with six buyers to choose from). It does not contradict the annotations, which flag a non-read-only, open-world tool. It says nothing about persistence, cost or latency of the generation call, which keeps it below a 5.

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 the trigger and the default condition before describing the output shape, so the key routing information comes first. The middle sentences are dense, and the parameter recap partially repeats the schema, but none of it is filler.

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 carries the job of explaining the return value, which it does well, and it also covers the fallback path. The omission of stage (required for a deal meeting) and companyName leaves a small completeness gap for a 6-parameter 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a little procedural framing around the meeting inputs and the omitted-room behaviour, but it never mentions the stage or companyName parameters, and the schema does more work than the prose does.

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?

Opens with a specific verb, resource and trigger ('prepare for an upcoming meeting'), then describes exactly what comes back: what the meeting is for and what each person in the room thinks going in. It reads clearly against siblings such as simulate_buyer_persona and generate_portfolio_brief.

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?

States when to use it ('the person has a specific upcoming meeting or call and wants to be ready'), calls itself the default for 'prepare me for my call', and names the alternative plus the condition that selects it ('To talk with the buyers before the meeting, use simulate_buyer_persona with the same brief').

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