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

With no annotations present, the description carries the behavioral burden and does disclose meaningful execution semantics: it fetches today's calendar and researches attendees in parallel with deduplication, which signals cost/scope behavior an agent should anticipate. It does not say whether anything is persisted or what happens on a day with no meetings, leaving a modest gap.

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 short sentences, front-loaded with the scope constraint, and the mechanism (parallel, deduplicated research) is compressed into a parenthetical rather than explicated. Nothing is wasted and nothing essential is buried.

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?

The tool is zero-parameter and has an output schema, so return values need not be described. Scope, execution behavior, and intended use are all covered, leaving nothing an agent needs in order to invoke it 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?

The tool takes no parameters and the schema has 100% coverage with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter claims are made that could mislead.

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 (Generate) and resource (meeting briefs) with an explicit scope qualifier (ALL of today's meetings), which implicitly separates it from single-meeting siblings like get_meeting_brief and history-oriented ones like brief_with_history. It stops short of naming any sibling explicitly, so differentiation is inferred rather than stated.

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?

"Perfect for morning prep" gives a use-case context, but there is no when-not guidance and no comparison against the many nearby alternatives (brief_with_history, get_outlook_brief, get_meeting_brief). The agent can infer the intended scenario but must guess about the alternatives.

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?

With no annotations, the description carries the full burden and does disclose the internal pipeline: live calendar lookup, parallel attendee web research, memory-DB history, and prior action items. It hints at latency (parallel research) and data sources, though it does not state read-only status, permissions, or failure behavior.

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-loads the core action in the first sentence, then uses a numbered breakdown that maps cleanly to its three internal stages. Slightly verbose in the closing sentence, but every part is informative and nothing is wasted.

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 explained, and both parameters are covered by the schema. The description adequately conveys what the tool aggregates; only the operational caveats (latency, permissions) are absent, which is a minor gap for a read-style brief generator.

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 meeting_id (with priority note) and meeting_title. The description adds no parameter guidance of its own, so the baseline 3 applies.

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 (Generate) and resource (pre-meeting brief including past interaction history), then explicitly distinguishes itself from the sibling get_meeting_brief by framing itself as the richer superset. An agent can tell exactly what it produces versus the plain brief.

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 use condition — 'especially valuable for recurring meetings and follow-up calls' — and references get_meeting_brief as the lighter alternative it builds on. It stops short of an explicit when-not rule (e.g. 'use get_meeting_brief when no history is needed'), so it is strong but not complete routing guidance.

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?

No annotations are provided, so the description carries the full burden — and it does disclose real behavioral traits: the record is persisted ('saved to memory'), a follow-up email draft is generated, and action items are auto-extracted from notes if omitted. It does not cover failure modes (e.g., meeting_title not matching a calendar event), idempotency, or whether re-running overwrites an existing record.

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 one-line purpose followed by clearly labeled Provide/Returns sections; each bullet carries information. The Returns block partly duplicates the output schema, which is minor redundancy rather than noise.

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 not strictly required, but the description's disclosure of the memory-write side effect is valuable. The remaining gap is edge-case behavior when the meeting title does not resolve to a calendar event, and any permissions/calendar-scope requirements, for a tool with zero annotation coverage.

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 must compensate entirely, and it does: every one of the 4 parameters is explained with format and intent (comma-separated task/owner lists, raw notes accepting bullets or transcript snippets, title matching a calendar meeting or just a name). Optional vs required is also made explicit, which the bare schema only conveys via the required array.

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 ('Record what happened in a meeting') plus a secondary capability (generate follow-up materials). This is the only write/record tool among siblings that are all retrieval or preparation tools (get_meeting_brief, search_meeting_history, etc.), so an agent can distinguish it 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 description implies when to use it (after a meeting, to capture notes) and clarifies optionality of action_items/outcomes, but it never explicitly states when to use this versus siblings, nor any preconditions beyond the parenthetical about calendar matching. Usage is inferable but not routed.

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?

With no annotations, the description carries the full burden, and it does disclose a real behavioral trait: the HUBSPOT_API_KEY environment prerequisite and the implication that CRM enrichment is unavailable without it. It also reveals the tool fans out into parallel web research, hinting at latency/cost, but says nothing about rate limits, partial-failure behavior, or the degraded output shape when the key is absent.

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?

Four short sentences, each earning its place: purpose, composition, usage, and prerequisite. The core purpose is front-loaded in the first sentence with zero preamble or 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 explained, and the description covers composition, intended use, and the auth prerequisite. The remaining gap is behavioral: it never clarifies what the brief looks like without the CRM key or how slow the parallel research step is, which matters for a tool that chains three sources.

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% and there is a single parameter, so the schema already explains that meeting_title is a partial-or-full Calendar lookup string. The description adds no additional matching semantics (e.g., case sensitivity, ambiguity handling), so the baseline 3 applies.

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 ('Generate a meeting brief enriched with HubSpot CRM data') and then enumerates the three data sources it composes (Calendar lookup, parallel web research, HubSpot deal context). That composition detail is what lets an agent separate this from siblings like brief_with_history or get_meeting_brief without opening a 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?

Gives a clear when-to-use signal ('sales meetings, partner reviews, and customer calls where CRM context matters') and a prerequisite (HUBSPOT_API_KEY). It does not name an alternative tool or state when NOT to use this one, so it stops short of the explicit routing that a 5 requires.

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?

With no annotations, the description carries the full burden. It does add real behavioral context by listing the returned fields and disclosing the HUBSPOT_API_KEY/.env configuration requirement, which tells the agent the integration may be disabled. It still omits what happens when the key is missing, whether the call is read-only, and any rate or lookup-miss behavior.

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, front-loaded blocks: the action first, then the payload, then the setup caveat. No filler sentences, though the setup note could have been folded into the first line for even tighter structure.

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 is not obligated to explain return values, and it still summarizes them usefully. The auth prerequisite is surfaced, leaving only sibling-routing guidance as a meaningful gap.

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% and each parameter is documented in the schema, so the baseline is 3. The description adds no parameter-level detail (matching semantics, whether name alone is sufficient, how company narrows results) beyond what the schema already states.

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 ('Look up a person in HubSpot CRM') and enumerates the returned data fields, which makes the tool's scope unambiguous. It does not, however, distinguish itself from the sibling 'enrich_brief_with_crm' or 'get_person_history', 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?

The description never says when to reach for this tool versus the many adjacent siblings (enrich_brief_with_crm, get_person_history, research_attendee). No prerequisites, triggers, or exclusions are given beyond the setup note.

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?

With no annotations, the description carries the full burden and does disclose real behavior: it looks up a specific calendar, fans out attendee research in parallel, and composes a brief card. It omits latency/cost expectations (parallel research implies a slow, expensive call) and any calendar-permission requirements, but the read-only, non-mutating character is clear from 'generate'/'look up'/'researches'.

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 one-line purpose, then mechanism, then a tight bulleted list of what the brief contains. Efficient overall, though the output bullets partially duplicate a return shape that an output schema already covers.

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 3-parameter read tool with 100% schema coverage and an output schema, the description supplies the missing high-level picture: what is researched, in what manner, and what the resulting brief looks like. The main remaining hole is selection guidance among the many overlapping brief/meeting siblings.

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 meeting_id, hours_ahead, and meeting_title, including the priority rule for meeting_id. The description adds nothing about any of the three parameters, so it sits at the baseline rather than compensating.

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 ('Generate a full pre-meeting intelligence brief for a single meeting') and the single-meeting scope implicitly separates it from brief_all_today. However, no sibling is named, so it is not self-evidently distinct from the near-identical brief_with_history in the sibling list.

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?

'Pre-meeting' implies the timing context, and naming Google Calendar as the source implies the Outlook siblings (get_outlook_brief) are the alternative for other calendars. But there is no explicit when-to-use, no when-not, and no routing against brief_with_history or brief_all_today, which overlap heavily with this tool.

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?

With no annotations, the description carries the full burden. It discloses useful behavior: what fields are returned (task, owner, meeting context, age-open) and the criterion that makes an item 'open'. It does not say whether results span all meetings indefinitely, whether there is a time window or pagination limit, or what distinguishes an empty result.

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 core action and followed by return contents and the definition of 'open'. Every sentence adds information; nothing is wasted or redundant.

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-value documentation is not required, and the zero-parameter read-only nature keeps the surface small. The description covers scope and content adequately, though it omits the time window over which 'past meetings' are scanned and the ordering of results.

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 schema imposes nothing to document and the baseline is 4. The description adds no parameter information because none is needed.

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 ('List') and resource ('open action items from past meetings'), and defines what 'open' means, so the agent knows exactly what comes back. It does not name or contrast any sibling tool, but no sibling overlaps this function, so the purpose is still unambiguous.

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?

Usage is implied — call this to surface outstanding tasks from prior meetings — and the definition of 'open' (follow-up not marked done) is genuinely useful context. However, there is no explicit when/when-not guidance and no routing to alternatives like search_meeting_history or debrief_meeting.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the setup prerequisite (AZURE_CLIENT_ID must be set in .env), which is real operational context, but says nothing about read-only nature, latency, or failure behavior when the credential is missing.

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 short sentences, front-loaded with the action and scope, then the sibling comparison and prerequisite. Every sentence earns its place with no padding.

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 explained, and all three params are documented in the schema. The description covers purpose, sibling routing, and the credential prerequisite; only richer behavioral detail (e.g., what happens without AZURE_CLIENT_ID) 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 meeting_id, hours_ahead, and meeting_title are already fully documented, giving a baseline of 3. The description adds no parameter-level meaning (e.g., priority between meeting_id and meeting_title) beyond what the schema states.

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 (Generate) and resource (a meeting brief) plus the data source (Outlook/Microsoft 365 calendar). It also explicitly distinguishes itself from the sibling get_meeting_brief by naming the differing backend (Google Calendar vs Microsoft 365).

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?

Points the agent at the alternative (get_meeting_brief) and gives the selecting condition (Microsoft 365 vs Google Calendar) plus a prerequisite (AZURE_CLIENT_ID in .env). It stops short of an explicit when-not statement, but the routing condition is clear.

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?

With no annotations, the description carries the full burden and does disclose real behavioral context: it requires AZURE_CLIENT_ID configuration to be enabled and triggers a first-run device-code auth flow. What it omits is the read-only safety profile and any error/empty-calendar behavior, but the auth onboarding disclosure is substantive beyond a bare verb.

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 paragraphs, front-loaded with the core action, followed by the setup prerequisite and the return-format reference. Every sentence is relevant, though the auth paragraph is slightly more operational detail than selection guidance.

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 needn't explain return values, and the one optional parameter is fully covered by the schema. The auth prerequisite is surfaced, leaving only minor gaps around read-only semantics and failure modes for a tool with no annotations.

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 hours_ahead and its 24-hour default are already fully documented in the schema. The description adds no supplementary syntax or boundary detail beyond that, which is the expected baseline when structured data does the work.

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 (get upcoming meetings from Outlook/Microsoft 365 calendar) and disambiguates the data source from the Google variant by naming get_upcoming_meetings as the format reference. An agent can tell which calendar backend this targets, though it doesn't explicitly say it is the Outlook counterpart to use instead of the Google tool.

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 source qualifier (Outlook/Microsoft 365) implies when this tool is appropriate versus get_upcoming_meetings, and the AZURE_CLIENT_ID line implies a precondition. However, there is no explicit when-to-use/when-not statement nor a direct routing sentence pointing to alternatives.

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?

No annotations are provided, so the description carries the behavioral burden, and it does disclose the categories of content returned (past meetings, topics, commitments, outcomes). However, it says nothing about permissions, result size/limits, pagination, or whether history is scoped to a workspace, leaving real behavioral gaps for a no-annotation tool.

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 short sentences, front-loaded with the core action and followed by the enumerated content. No filler, no restating of the title, and every clause carries 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 single-parameter read tool with a full output schema, the description adequately frames what the tool returns and why. The absence of annotations means some behavioral detail (limits, scoping) is arguably missing, but the core need is well covered.

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% and there is a single 'name' parameter already documented as 'Full or partial name of the person to look up.' The description mentions 'a specific person' but adds no syntax, matching behavior, or ambiguity handling beyond that, so the baseline 3 applies.

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 ('Get') and a well-defined resource ('full interaction history with a specific person'), and the second sentence enumerates the content (meetings, topics, commitments, outcomes). It never distinguishes itself from close siblings like research_attendee or search_meeting_history, so an agent cannot disambiguate from this 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?

There is no statement of when to use this tool versus alternatives. Siblings such as research_attendee, search_meeting_history, and brief_with_history plausibly overlap, yet the description offers no boundary conditions, prerequisites, or exclusions to guide selection.

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?

With no annotations, the description carries the full behavioral burden. It discloses the data source and the forward-looking window, which is useful, but says nothing about whose calendar is read, auth requirements, timezone basis, or empty-result behavior.

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?

The purpose is front-loaded in one tight sentence. The follow-on return-field list is slightly redundant given an output schema exists, but it is compact and well-structured.

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 simple read tool with one optional parameter and an existing output schema, the description covers purpose and scope adequately. Only timezone/auth context is absent, which is a minor gap.

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% and the single optional hours_ahead parameter is documented with its default in the schema. The description only restates 'next N hours' and adds no format or boundary detail beyond that baseline.

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 (Get), resource (upcoming meetings), and source (Google Calendar) with an explicit time scope (next N hours). This cleanly separates it from the sibling get_outlook_meetings, which covers a different provider.

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 'from Google Calendar' qualifier implicitly routes the agent away from get_outlook_meetings, but there is no explicit when-to-use statement, no mention of when to prefer search_meeting_history or get_meeting_brief, and no stated prerequisites.

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?

There are no annotations, so the description carries the full behavioral burden, and it does add one genuinely useful trait: a 60-minute cache that makes repeat calls free of new API requests — a real cost/latency signal an agent can plan around. It omits the rest of the profile though: that this hits an external enrichment API, what happens for an unknown or ambiguous person, whether it fails soft or hard, and whether there is any cost or rate limit on the first call.

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 short sentences, zero filler. The purpose leads, and the caching caveat follows as supporting operational detail rather than burying the lede.

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 100% schema coverage and an output schema present, the description needn't explain parameters or return values, and it supplies purpose plus a caching trait. What keeps it from a 5 is the absence of any routing signal among the many overlapping sibling research/enrichment tools, which is the main thing an agent could still get wrong.

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 all three parameters are already documented in structured form, and the description adds nothing above that baseline. It never mentions that 'company' and 'context' improve accuracy — a meaningful hint that lives only in the schema, not the description. Baseline 3 applies.

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?

A specific verb ('Research') plus a specific resource ('a meeting attendee') and an enumeration of what the research returns: current role, company news, background. This is far more than a restatement of the name. It doesn't, however, distinguish itself from the closely related siblings get_person_history and get_crm_context, whose scopes overlap enough that an agent could plausibly reach for the wrong one.

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?

No sentence says when to call this instead of get_person_history or enrich_brief_with_crm, or what the prerequisites are (does it need an existing meeting? an email address?). The only usage-adjacent content is the caching note, which tells the agent re-calling is cheap but not when calling is appropriate at all.

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?

With no annotations, the description bears the full burden, and it does add meaningful mechanism context (FTS5 full-text search) and lists the indexed surface (titles, attendees, summaries, action items, outcomes). It stops short of disclosing pagination/limit behavior or how relevance/ranking works, so it is adequate but not rich.

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 lines, front-loaded with the core action before elaborating on fields and mechanism. Efficient with little waste, though the FTS5 implementation detail is arguably more developer-facing than agent-facing.

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 simple two-parameter search tool with a full output schema, the description covers purpose, queryable fields, and search mechanism. The one gap is sibling differentiation against get_person_history, whose name overlaps heavily with this tool's purpose.

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 both parameters are already documented by the schema; baseline is 3. The 'Query by person name, company name, topic, decision, or date' line adds slight meaning to the query parameter but no syntax or format guidance beyond 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 clear verb+resource ('Search your past meeting history') and enumerates the fields that can be queried. However, it does not distinguish itself from sibling get_person_history, which also seems to retrieve past interactions with a person, leaving the agent to guess which to call.

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 examples of queryable dimensions (person, company, topic, decision, date) imply usage context, but there is no explicit when-to-use/when-not and no mention of alternatives like get_person_history or research_attendee when the target is a specific person.

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