FounderBrain

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds genuinely new behavioral context: restricted information must be stripped before transfer per server instructions, and a user-selected excerpt is acceptable. It also constrains the input to a complete prepared transcript rather than a file preview. Return format is left to the output schema, so this is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence and the parameter guidance follows immediately. The indented block is slightly awkward in layout but every clause carries actionable information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and it covers input format, completeness requirements and privacy handling. For a single-parameter read-only tool this is essentially complete, with only the sibling-routing condition left implicit.

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

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

Schema description coverage is 0% for the single transcript parameter, so the description must carry the burden and does: it specifies it must be the complete prepared transcript (not a file preview), one speaker turn per line in "Name: words" form, with restricted data removed and excerpts permitted. That is substantial semantic detail the schema lacks.

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

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

The description states a specific verb and resource ("List the speakers in a meeting transcript and how many words each said") and adds the scope-limiting clause "without scoring anything," which implicitly separates it from analyse_transcript. An agent can tell what it returns (speaker names + word counts) without opening the schema.

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

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

The phrase "without scoring anything" implies this is the lighter-weight alternative to a scoring tool, and the sibling analyse_transcript is the obvious alternative, but it is never named and no explicit when-not condition is given. Usage is inferable rather than stated, which lands at the minimum-viable level.

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

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

Goes well past the annotations (readOnly/idempotent/non-destructive) by ruling out side effects the agent might otherwise fear: it does not open a terminal, read the file, upload data, or execute anything, and does not inspect or clean the file. It also discloses the conditional output mode when speaker is omitted, which is genuine behavior an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-sentence purpose, followed by a boundary statement and then parameter meaning — a sensible order with no filler. The ragged line breaks and indentation make it slightly harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description correctly avoids describing return values and instead covers the intent, boundaries, and all four parameters. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0%, so the description carries the full burden and largely meets it: it defines path's expected contents and provenance, constrains role to 'answering' or 'asking' (information absent from the schema, which has no enum), and explains speaker/name as a fallback pair for generic labels. It omits that name/speaker/role are optional with defaults, leaving that to the schema.

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

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

States a specific verb and output ('Return a curl upload command as text') for a specific resource ('a prepared local transcript copy'), and sharply bounds the behavior ('only constructs the command'). It never names the sibling tools (analyse_transcript, check_transcript), so the agent must infer the workflow position rather than being told directly.

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

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

Gives a clear usage context: 'The caller runs the command in the user's terminal to send the copy to FounderBrain', plus a conditional behavior hint ('Without a speaker the command only lists the speakers and their word counts') that helps the agent decide whether to supply a speaker. It stops short of explicit when-not-to-use conditions or naming the sibling tools as alternatives.

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