Skip to main content
Glama
Sign In

Andru

by io.github.geter-andru
OverviewDiscussionsAdmin

Prepare for a meeting

get_pre_brief

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

NameRequiredDescriptionDefault
roomNoWho will be there: up to 8 people, each with their title and, if you know it, which of the six buyers they are.
stageNoWhere the deal is, by the last thing the buyer did (required for a deal meeting).
meetingNoThe 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'.
meetingIdNoThe meeting from the person's calendar (an id from a previous reply). Leave it out and describe the meeting in `meeting` instead.
situationNoWhat kind of meeting: a discovery call, where they speak first; a deal meeting (demo, pricing, pilot, procurement); or a customer review.
companyNameNoCompany you're meeting. Andru looks for the matching meeting on the person's calendar.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • 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"
+}
  2. Changed1 schema field changed
    • 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"
+}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations, the description discloses provenance and epistemic status: the brief is built from the account's buying committee and labelled as Andru's assumptions to correct. It also describes the fallback response (six buyers to choose from) when no attendees are given. It doesn't explain why readOnlyHint=false is set or whether the call persists anything, which is the one remaining behavioral gap.

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?

It is front-loaded with the trigger, then the return shape, then the input recipe, then the alternative tool - a sensible order. It is a bit dense at roughly five sentences, with the calendar/sentence input guidance restating what the schema already says, but nothing is truly 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?

With no output schema and six optional parameters, the description carries the burden well by narrating the brief's contents and the empty-room fallback. The notable omission is any explanation of what the `stage` integers 0-7 mean, which the schema's one-line description does not resolve either.

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 guidance the schema lacks: the either/or relationship between a calendar meeting and a one-sentence description, the emphasis on titles for attendees, and the consequence of leaving `room` empty. The `stage` 0-7 scale is still never explained in prose, which keeps it from a 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?

The description uses a specific verb+resource (generate a pre-meeting brief for a named meeting) and spells out the artifact's contents: purpose of the meeting plus each attendee's wants, objections, motivators, and disagreements. It also distinguishes itself from the nearest sibling by naming simulate_buyer_persona for the conversational variant.

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?

It states exactly when to invoke it ("the person has a specific upcoming meeting or call and wants to be ready"), declares itself the default for phrasings like "prepare me for my call", and explicitly routes the adjacent need (talking to buyers) to simulate_buyer_persona. It also covers the degradation path when the room is omitted.

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

All Andru toolsInspect
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