MeetNotes

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that: the REVISION_CHANGED error for a changed meeting and the fact that a part id embeds the meeting revision, both of which affect how the caller handles results.

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?

A single front-loaded sentence led by the imperative 'Use this to open...', with the payload description following. Dense but every clause (document kinds, id semantics, error code) carries information; 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?

An output schema exists, so return values need not be described, and the description still covers the two result shapes at a high level plus the id-format caveat and error behavior. For a one-parameter read tool with full annotation coverage, nothing essential 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% (the id property carries no description), so the description must compensate, and it does: it explains that the id may denote either a meeting or a transcript part and that a part id includes the meeting revision. That is materially more than the bare 'string, 1-200' schema constraint.

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 gives a specific verb and resource ('open one meeting document by its id') and enumerates the two document kinds it can return (meeting overview vs. a single transcript part). It is clear on its own, but never names the overlapping sibling meetnotes_get_transcript, so an agent cannot fully disambiguate from the text alone.

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?

'Use this to open one meeting document by its id' implies the usage context but states no when-not condition and no alternative. Given a sibling named meetnotes_get_transcript, the absence of any routing guidance between the two leaves the choice 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new context the annotations cannot convey: the text is generated from the public website, names its source pages, and touches no user meeting data. Only return-format detail is absent, and an output schema exists to cover that.

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?

Three short sentences, front-loaded with the trigger condition, then scope, then provenance. No filler and nothing repeated from the schema or annotations.

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?

For a single optional enum parameter with full schema coverage, rich annotations, and an output schema, the description supplies everything an agent needs: when to call it, what it returns conceptually, and where the data comes from.

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 100% and the enum values are self-explanatory, so baseline is 3. The description adds value by reframing the topics as natural-language user questions, helping the agent map a query to the right topic value rather than reading the enum cold.

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+resource ('Facts about the product' for MeetNotes itself) and scopes it as product-information retrieval, which cleanly separates it from every sibling that deals with the user's meetings, recordings, or transcripts.

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 an explicit trigger ('when the user asks about MeetNotes itself') and enumerates the question types that qualify (cost, platforms, notetaker, comparison, privacy, languages). It stops short of naming a sibling alternative or stating a when-not-to-use, but the boundary is clear from 'Reads nothing from the user's meetings.'

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=false, idempotentHint=true, destructiveHint=false and openWorldHint=false; the description goes beyond them by disclosing that the export is private, that it returns a completed job with an authenticated, expiring download link, and that it does not re-process audio or consume minutes. That cost and link-lifetime context is genuinely useful, though it says nothing about permissions or failure modes.

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?

Two sentences, front-loaded with the usage trigger, and every clause carries information (formats, scoping, privacy, non-reprocessing). It is dense but slightly overloaded with parenthetical formats where a single list would read faster.

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?

An output schema exists, so explaining return values is optional, yet the description still summarizes the result (a completed export job with an authenticated expiring link). Combined with the format/section coverage and the explicit non-share clarification, an agent has everything needed to call this correctly.

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?

With 50% schema coverage the description must compensate, and it does: it enumerates the format targets (PDF, Word/docx, Markdown, text, JSON) and explains that sections can be chosen or omitted for the whole document, clarifying the sections parameter. It does not clarify revision's precondition semantics beyond what the schema says, and meeting_id remains undescribed.

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?

Specific verb (export) plus resource (a finished meeting) and explicit output formats and section scoping. It also carves out a distinction from a public share link, but it never names or distinguishes against the actual sibling tools (fetch, meetnotes_get_transcript, meetnotes_list_recordings), so full sibling differentiation is absent.

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 opening 'Use this when the user wants to download, save or share...' gives a clear trigger condition, and the 'it is not a public share link' clause rules out one near-miss. There is no explicit guidance on when to prefer meetnotes_get_transcript or other siblings instead, so exclusions are partial.

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 readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds useful content-level context about what the payload covers and even surfaces the 'how to add a new recording' path, though it says nothing about rate limits or freshness of the capability data.

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?

A single dense sentence front-loads the returned content and closes with the usage trigger. No filler, nothing repeated from annotations or schema.

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?

For a zero-argument read-only discovery tool with a full output schema and complete annotation coverage, this description supplies everything an agent needs to decide to call it and what to expect.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already shows.

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 gives a concrete inventory of what the tool returns (bound account, languages, export formats/sections, page limits, how to add a recording), which is far more specific than the name alone. It stops short of differentiating itself from the sibling meetnotes_about, which an agent could reasonably confuse it with.

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?

It states an explicit trigger: 'Use this when unsure what the connected account supports.' That is a clear context for invocation, but no when-not condition or named alternative (e.g. meetnotes_about) is offered.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the tool returns job state plus next_poll_after_seconds, which tells the agent how to pace polling rather than hammering the endpoint. It does not cover failure/expiry behavior of jobs, so it stops short of 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.

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

Three tight sentences, front-loaded with the use case before the return details. The final sentence about minutes_markdown partially duplicates what the output schema already provides, but it usefully signals that a completed job yields the minutes directly without a follow-up call.

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, return values need not be re-explained, and the description correctly focuses on the polling workflow and next_poll_after_seconds. The main remaining gap is not telling the agent where job_id comes from, which matters for a tool whose only input is that id.

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?

Only one parameter, job_id, and schema coverage is 0%, so the description must carry the load. "By its id" gives the parameter meaning, but it never says where that id originates (e.g., returned by meetnotes_export_meeting or meetnotes_invite_notetaker) or what format it takes. Minimum viable.

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 (check status) and resource (a job by id), and enumerates the job types it covers (export, notetaker invitation, meeting/recording still processing). This clearly separates it from siblings like meetnotes_list_recordings, meetnotes_get_transcript, or fetch, which return content rather than async job state.

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?

"Use this to check on ... something that is still processing" gives a clear trigger condition: pending async work. It does not name a sibling alternative or state when not to use it, but the condition is unambiguous enough that an agent can route correctly.

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 read-only, idempotent, non-destructive behavior. The description adds useful pagination mechanics (next_cursor, complete flag) and return structure (segments with speaker, timing, link), which go beyond the annotations.

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?

Three sentences, front-loaded with usage context followed by behavioral details. No redundant or filler phrasing; each sentence contributes useful information.

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?

For a straightforward read-only retrieval tool, the description covers purpose, when to use it, return shape, and pagination. Output schema exists so return values need not be explained, but the remaining gap is thin parameter guidance for meeting_id and cursor input.

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 low (33%, only page_size documented). The description implies cursor semantics through 'next_cursor returns the next page', but does not explain meeting_id or page_size. It partially compensates for the gap but leaves two parameters under-specified.

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 action ('reads a transcript') and resource, with concrete content details (who said what, speaker labels, timestamps, exact words). It is clearly distinct from siblings like list_recordings or export_meeting, though it does not name an alternative explicitly.

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?

It gives a clear usage context: 'Use this when the user wants the transcript of a meeting...'. No exclusions or named alternatives are provided, but the trigger condition is unambiguous.

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 beyond the annotations: it discloses asynchronous behaviour (immediate job receipt with job_id, processing continues server-side), a cost consequence (spends the connected account's minutes), idempotency mechanics with the deduplicated flag and no re-charge, and an input restriction (audio only, size limit). These are exactly the traits an agent needs and none are derivable from the structured fields.

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 usage trigger, then behaviour, cost and constraints in dense declarative sentences with no filler. It is a single long paragraph, but nearly every clause earns its place; only the language-coverage sentence borders on marketing.

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?

Given a nested-object schema and an output schema that covers return values, the description supplies everything else: async contract, cost, dedupe, and input limits. Nothing an agent needs in order 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.

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

Schema description coverage is 100%, so the schema already documents file, title, language_hints and output_language. The description adds only indirect colour (100+ languages, mixed-language Hinglish) without clarifying tag format or the file object. Baseline 3 applies when the schema carries the semantics.

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+resource ('transcribe an attached audio file') and enumerates the concrete inputs it covers (meeting, call, interview, lecture, voice note). It clearly separates this from siblings that fetch or list existing meetings by framing it as the entry point for a newly attached file.

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 trigger condition is explicit and rich — 'when the user attaches an audio recording and wants it transcribed or turned into meeting notes.' It does not, however, name the sibling alternatives an agent should pick instead when the recording already exists in MeetNotes (e.g. meetnotes_list_recordings or meetnotes_get_transcript), nor state when-not-to-use.

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?

Far exceeds the annotations: discloses the visible participant identity, the waiting-room admission requirement, that recording runs until call end, that it spends account minutes, the async receipt/job_id flow, the deduplicated-response behavior, and the 2-active-invitation cap. These are exactly the operational traits an agent needs beyond readOnlyHint=false and destructiveHint=false.

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 triggering scenario, then behavior, then return contract. Dense but every sentence carries information; only the app-routing sentence is marginal. Slightly long for a single tool but not padded.

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?

For a write tool with an output schema, it still explains the async lifecycle (immediate job_id, later meeting id, then minutes) and the invite cap, so an agent knows both what it gets back and what constraints apply. Nothing required for correct invocation 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 already 100%, so baseline is 3. The description adds real meaning beyond the schema: join_at can mean 'now' when omitted or past, meeting_url may be raw joining text pasted around the link, and output_language governs the language minutes are written in.

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+resource ('Invites the MeetNotes Notetaker into the call from its link') and names the trigger condition (user shares a Meet/Zoom/Teams link wanting recording, transcription, or minutes). An agent can distinguish it from siblings like meetnotes_import_audio or meetnotes_get_transcript without opening schemas.

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?

Clear context for when to invoke: user shares a call link and wants it recorded/transcribed/summarized. It also discloses the dedup path and notes that leaving early or cancelling a booking happens in the MeetNotes app (routing away from this tool), but it does not name a concrete alternative tool for adjacent needs.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations don't: results are restricted to 'finished meetings', and fields like due date and transcript segment are only present 'when one was resolved' / 'when it can be located', warning the agent about nullable outputs. It omits any mention of pagination despite the cursor/page_size parameters.

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?

Three sentences, front-loaded with the trigger condition before the return shape and filters, with no filler. Slightly more compact would be possible, but each sentence carries distinct information.

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?

An output schema exists, so the description doesn't need to detail return values, yet its brief field list is a helpful preview. For a zero-required, five-parameter list tool it covers triggers, scope, and filters adequately; the remaining gap is pagination/filter-format guidance for the undocumented parameters.

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 only 40% (cursor, status, and meeting_id are undocumented in the schema), so the description must compensate. 'Filter by meeting, status or due date' does map onto three of the five parameters, but it adds no format or value detail (e.g. that status is open/done, that meeting_id is an opaque id) and says nothing about cursor or page_size, leaving a real coverage gap.

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 gives a specific verb and resource ('Returns action items from the connected user's finished meetings') plus the exact scope, so the agent can tell it apart from siblings like meetnotes_list_recordings, meetnotes_get_transcript, or search without opening a schema. It also enumerates the surface (owner, status, due date, transcript segment) which no sibling tool returns.

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 opening sentence gives explicit trigger phrasing ('Use this when the user asks for action items, tasks, follow-ups, owners, deadlines or pending work'), which maps user intent directly onto the tool. It stops short of naming when NOT to use it or pointing at an alternative such as search/fetch for cross-meeting keyword lookup.

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 cover the read-only, idempotent, non-destructive safety profile, so the bar is lower. The description still adds useful behavior: results are ordered newest first and include processing state plus the meeting id consumed by downstream tools, which helps an agent chain calls. It doesn't mention pagination behavior, but a good chunk of the behavioral burden is met.

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?

A single dense sentence that leads with the usage triggers, then states scope, ordering, and returned fields. No filler, no restating of the title, and the most decision-relevant content is front-loaded.

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 and rich annotations, the description needn't explain return values, and it covers usage, scope, and ordering well. The only real gap is pagination/continuation semantics for cursor, which is left entirely to the schema.

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 50% — query and page_size are documented, cursor and created_after are not. The description only implicitly maps 'find one by title or date' onto query/created_after and adds no syntax or format guidance, so it neither compensates for the coverage gap nor adds much beyond the schema. Baseline 3 is apt.

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 ('Lists the connected user's own recordings'), and adds scope details ('newest first, with processing state and the meeting id other tools take') that let an agent distinguish it from sibling tools like search or fetch. The scoping to the connected user's own recordings is a meaningful differentiator.

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?

It gives explicit when-to-use triggers: recent/latest/past meetings, finding one by title or date, or checking processing status. What's missing is a negative boundary — a sibling named 'search' exists, and the description never says when to prefer that over this list tool, leaving overlap unresolved.

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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it searches only *finished* meetings, matches 'by words or meaning' (keyword plus semantic), and returns overview documents plus transcript parts keyed by an id that opens the full item.

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?

Two sentences: the first front-loads usage triggers, the second front-loads what is searched and what comes back. No filler; every clause adds information about scope, matching mode, or return shape.

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?

An output schema exists, so return values need not be detailed, yet the description still summarizes the return form (documents + transcript parts with ids). It covers scope, matching mode, and output form; missing are result limits, pagination, or whether results are ranked, which an agent searching a meeting corpus might need.

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?

With one parameter at 0% schema description coverage, the description carries the burden, and it partially does so by demonstrating free-form natural-language queries in the trigger examples, implying the query is prose rather than keyword syntax. It never addresses the 300-character cap or minimum length, so the gap is only partly closed.

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 ('Searches the connected user's finished meeting minutes and transcripts') and scopes it to finished meetings, which cleanly separates it from siblings like fetch, meetnotes_get_transcript, and meetnotes_list_recordings. An agent can identify what it does 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 opening clause gives concrete user-utterance triggers ('what did we decide about pricing?', 'when did we talk about the launch?') that map intent to tool selection, which is strong when-to-use guidance. However, it names no explicit alternatives or exclusions (e.g., 'use fetch when you already have a meeting id'), so routing against siblings is left partly to inference.

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