FounderBrain

Analyse a meeting transcript

analyse_transcript

Read-onlyIdempotent

Compare one speaker in a meeting transcript with public founder and operator interviews and return the report as data: speaking type, style positions, similar well-known people, standout habits and takeaways.

    transcript: the complete prepared transcript, never just a file preview, one speaker turn per line
    ("Name: words"). Restricted information must be removed before transfer, as described in the server instructions;
    a user-selected excerpt is allowed. speaker: one speaker label as it appears in the text.
    name: the person's display name when the label is generic (Me, Them, Speaker 2), or "You" when
    the speaker is the user; required for a generic label other than Me. role:
    "answering" when they were pitching or answering questions, "asking" when they mostly asked them. Needs at
    least 300 words from the speaker and at most 15,000 words in all; usually takes under a minute, up to about two minutes when the service is starting up. Clients that
    support MCP Apps also show the visual report.

Input Schema

Name	Required	Default
`name`	No
`role`	No	answering
`speaker`	No
`transcript`	No

Output Schema

Name	Required	Description
`note`	No	A note on reading the report, such as for a speaker who mostly asked questions.
`role`	Yes
`method`	No
`person`	Yes	The speaker as named in the report.
`styles`	Yes	Positions on four speaking styles, as percentiles against the reference interviews.
`speaker`	Yes	The speaker label analysed, as it appears in the transcript.
`coverage`	Yes	How much of the transcript was analysed, and whether the result is settled.
`headline`	Yes	One line on where the speaker differs most from the reference interviews.
`archetype`	Yes	The speaking type: name, sketch, description and best-known members.
`takeaways`	Yes	What to try next time and what to keep.
`how_to_use`	No	How the assistant should coach from these results.
`how_to_read`	No
`closest_match`	Yes	The well-known founder or operator whose style is closest.
`least_like_you`	No	The well-known person whose style is least alike.
`similar_people`	No	Other well-known people with a similar style, with match percentages.
`words_received`	Yes	Words in the transcript received.
`standout_habits`	No	Habits whose rate differs most from the reference interviews.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "archetype": {
+      "description": "The speaking type: name, sketch, description and best-known members.",
+      "type": "object"
+    },
+    "closest_match": {
+      "description": "The well-known founder or operator whose style is closest.",
+      "type": "object"
+    },
+    "coverage": {
+      "description": "How much of the transcript was analysed, and whether the result is settled.",
+      "type": "object"
+    },
+    "headline": {
+      "description": "One line on where the speaker differs most from the reference interviews.",
+      "type": "string"
+    },
+    "how_to_read": {
+      "type": "object"
+    },
+    "how_to_use": {
+      "description": "How the assistant should coach from these results.",
+      "type": "string"
+    },
+    "least_like_you": {
+      "description": "The well-known person whose style is least alike.",
+      "type": "object"
+    },
+    "method": {
+      "type": "string"
+    },
+    "note": {
+      "description": "A note on reading the report, such as for a speaker who mostly asked questions.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "person": {
+      "description": "The speaker as named in the report.",
+      "type": "string"
+    },
+    "role": {
+      "enum": [
+        "answering",
+        "asking"
+      ],
+      "type": "string"
+    },
+    "similar_people": {
+      "description": "Other well-known people with a similar style, with match percentages.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "speaker": {
+      "description": "The speaker label analysed, as it appears in the transcript.",
+      "type": "string"
+    },
+    "standout_habits": {
+      "description": "Habits whose rate differs most from the reference interviews.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "styles": {
+      "description": "Positions on four speaking styles, as percentiles against the reference interviews.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "takeaways": {
+      "description": "What to try next time and what to keep.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "words_received": {
+      "description": "Words in the transcript received.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "person",
+    "archetype",
+    "headline",
+    "styles",
+    "closest_match",
+    "takeaways",
+    "coverage",
+    "words_received",
+    "speaker",
+    "role"
+  ],
+  "type": "object"
+}

First observedSep 30, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare the safe-read profile (readOnly, idempotent, non-destructive, closed-world). The description adds material context beyond that: restricted information must be stripped before transfer per server instructions, a user-selected excerpt is acceptable, and the call usually runs under a minute but up to about two minutes on cold start. Word-count limits and the MCP Apps visual variant are also disclosed.

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 and the returned report fields are front-loaded in the first sentence, then parameters follow. It is dense and the long sentence bundling word limits, latency, and MCP Apps support is overstuffed, but nearly every clause carries actionable content rather than filler.

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?

Even though an output schema exists and return values needn't be restated, the description summarises the report contents, covers all four params, states hard input limits, and handles the privacy-sensitive transfer requirement. Nothing an agent needs to call this correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden — and it does. All four parameters are explained: transcript formatting ('Name: words', one turn per line, never a preview), speaker label matching, name semantics for generic labels including the 'You' convention and the Me exception, and the answering/asking values for role (which the schema lacks as an enum).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource chain: compare one speaker in a meeting transcript against public founder/operator interviews and return a structured report (speaking type, style positions, similar people, habits, takeaways). That is far more specific than a restated name. It does not, however, mention or distinguish itself from the sibling check_transcript, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete preconditions — at least 300 words from the speaker, at most 15,000 words total, full prepared transcript rather than a file preview, and how to interpret the role values. But it never says when to choose this over check_transcript or open_in_terminal, so the routing decision is left to inference.

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

All FounderBrain 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?