3GPP Scout

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

Annotations declare readOnlyHint=false, and the description explains why: it 'may download the source document and persist its parsed content in Scout's catalog', which is exactly the side-effect context an agent needs. It also discloses latency ('usually completes within 60 seconds') and that output is capped, adding value beyond 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 verb and resource, then side effects, then timing, then scope limitation — a sensible ordering with no filler. All four sentences carry information, though the closing negation could be folded into the opening scope statement.

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 no output schema, the description does cover the return shape (capped excerpts) and rules out full export, plus discloses the mutation, persistence, and timing. This is close to complete for a tool whose remaining parameters are well covered by 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 description coverage is 80%, so the schema already documents force/include/text_offset/max_text_chars in detail. The description only loosely gestures at the capping behavior ('capped excerpts'), adding little parameter-level meaning beyond what is already structured.

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 ('fetch and parse'), a precisely scoped resource ('one public 3GPP TDoc by number'), and the output shape ('capped excerpts'). An agent can distinguish it from the search_/list_tdoc siblings, but the description never differentiates it from the very similar 'get_tdoc' sibling, which is a real ambiguity.

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?

Provides a when-not ('Does not provide a whole-document export') that usefully rules out one class of intent. However, it gives no positive guidance on when to prefer it over get_tdoc or the search/list variants, leaving alternative selection 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=true, destructiveHint=false, and openWorldHint=false. The description's only behavioral claim, 'Does not create anything,' merely restates those annotations without adding new context such as auth needs, rate limits, or return behavior. No contradiction, but no added value beyond 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?

Two tightly worded sentences with zero waste. The core purpose is front-loaded, and the secondary clarification about not creating anything follows efficiently.

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-only discovery tool with a fully documented single parameter and clear safety annotations, the description is nearly complete. It could be slightly more explicit about the return format (e.g., a list of suggestions), but the phrase 'Suggest specs, work items or meetings' adequately implies what the agent will receive.

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 schema's query parameter description already provides rich examples (topic, company, spec, meeting, mix). The description adds no parameter-specific guidance beyond what the schema supplies, so the baseline of 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 clear verb (suggest) and resource (specs, work items, meetings) matching a topic to follow. It indirectly differentiates from follow_topic by stating 'Does not create anything,' but never names the sibling explicitly, leaving some ambiguity about where it fits in the discovery-to-follow workflow.

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?

Implies the tool is used when a user wants to discover topics to follow, but gives no explicit when-to-use guidance, no prerequisites, and no named alternatives (e.g., follow_topic or list_followed_topics). The agent must infer the context from the phrase 'wants to follow.'

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 only declare it is non-readonly, non-destructive and closed-world; the description adds real behavioral context beyond that: persistence to the user's account and an email-digest side effect. It does not detail the 409 confirmation_required flow in the prose (that lives in the confirmed param).

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 effects, then the precondition. Every sentence earns its place 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?

For a 7-parameter mutation tool with no output schema, the description covers the main action and confirmation gate but omits the delivery modes (enum with no description), created_via, and source_thread_id. Adequate but leaves notable gaps an agent might need when invoking.

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 57%, so the schema already carries much of the parameter meaning (label, query, targets, target_id, confirmed). The description reinforces the confirmation precondition but says nothing about delivery, created_via, or source_thread_id, so it adds only marginal value over 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?

The description states a specific verb+resource ('Follow a topic') and adds two concrete effects: saving to the Scout account and possibly sending email digests. It is clearly distinguishable from unfollow_topic and find_topics_to_follow, though it never names a sibling to sharpen the contrast.

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 precondition: 'Call only after the user confirms the targets,' which pairs with the confirmed/targets parameters. It offers no explicit when-not or alternative-tool routing, so it stops short of the top score.

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=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that it summarizes from TDocs, suggesting a synthesized return, but doesn't specify pagination behavior despite a cursor parameter or any other traits beyond 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?

A single, efficient sentence that front-loads the core action and resource. It is appropriately sized with no waste, though it could be slightly more specific about scope.

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 9 parameters, no output schema, and no annotations beyond safety hints, the description is too thin. It fails to explain how to combine filters like org/orgs, topic, stance, and meeting, or what the summary output includes, leaving significant gaps for such a complex tool.

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 78%, so most parameters are documented in the schema. The description doesn't add any parameter details beyond what the schema provides, making the baseline 3 appropriate.

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 (summarize) and resource (company positions on a topic from its TDocs), which is clear. However, it does not differentiate from the sibling search_positions, which likely returns position documents rather than summaries, leaving the agent to infer the distinction.

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 guidance on when to use this tool versus alternatives like search_positions or fetch_tdoc. There are no prerequisites or exclusions mentioned, leaving the agent without routing context.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that it returns metadata rather than document content, but says nothing about auth needs, rate limits, or error 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?

A single front-loaded sentence with no filler, which is appropriately sized. It is slightly vague in wording ('specification' vs 'document') 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?

An output schema exists, so return values need not be described, and annotations cover the read-only nature. Still missing is a tie-in to the surrounding document/tdoc tool family and any note on what 'metadata' excludes, leaving the agent to infer scope.

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 schema gives only a name and type for document_id. The description compensates slightly by indicating the parameter is an ID lookup, but adds no format, range, or expected value detail for the integer identifier.

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 ('get metadata for one specification') and scopes it to a single record by ID, which distinguishes it from list_documents_documents_get. However, it never names a sibling alternative and the terminology ('specification') doesn't clearly reconcile with the tool's own 'document' naming or with get_tdoc/list_tdocs.

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 explicit guidance on when to use this tool versus the many sibling lookup tools (get_tdoc, fetch_tdoc, list_documents_documents_get). The 'by its ID' phrasing only weakly implies the required input form; no prerequisites, no when-not conditions.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses nothing: no pagination behavior despite limit/offset params, no freshness semantics for 'recent', and no hint at what the updates contain.

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 efficient sentence with no padding, which is good structure, but its brevity comes at the cost of under-specification for a four-parameter tool. Appropriate size, insufficient substance.

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 no output schema and four parameters, the description would need to carry more weight. It omits pagination semantics, what a 'change' object looks like, and how follow_id is obtained, leaving real gaps for an agent 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?

Schema description coverage is only 25% (only 'since' is documented). The description mentions 'one followed topic', weakly implying follow_id is required, but says nothing about limit, offset, or pagination defaults, so it does not compensate for the 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?

States a specific verb (Get) and resource (recent changes for one followed topic), which distinguishes it from list_followed_topics and update_followed_topic. It is clear but does not explicitly name how it differs from its closest siblings, so it stops just short of a 5.

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 gives no when-to-use guidance, no prerequisites, and does not point to any alternative such as list_followed_topics for discovering follow_ids. The agent must infer usage entirely from the name.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond 'Get details' and does not describe permissions, side effects, or return 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?

It is a single front-loaded sentence with no wasted words, but it is under-specified for a tool with three parameters. The brevity is efficient yet leaves important context unstated.

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?

There is no output schema, so the description should explain what details are returned, but it does not. Combined with no usage guidance and incomplete parameter coverage, the definition is too thin for an agent to use confidently beyond the basics.

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 67%, with 'include' and 'documents_limit' well documented in the schema but 'meeting_id' undocumented anywhere. The description adds no parameter meaning beyond the schema, and it does not compensate for the uncovered required parameter.

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 and resource ('Get details of one meeting'), which distinguishes it from list_meetings by focusing on a single meeting. It does not explicitly name or differentiate from siblings beyond the singular object, so it is clear but not maximally specific.

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 provides no guidance on when to use this tool versus alternatives such as list_meetings or get_tdoc. It simply states what it does, leaving context and exclusions entirely 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=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful payload context by naming the return as a '3GPP participation summary,' but says nothing about what that summary contains or whether results are paged. With annotations carrying the burden, this is adequate but thin.

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 with no filler, no redundancy, and nothing that could be trimmed. Well structured for a simple lookup tool.

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 no output schema, the description is the only source on what comes back, and '3GPP participation summary' is too vague to tell an agent what fields or level of detail to expect. For a one-parameter read tool it is minimally sufficient, but the vague return description and unspecified org_id format leave real gaps.

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% and org_id has no description in the schema, so the description must compensate; it only implies that the identifier refers to a single organization. It does not state the expected format (numeric ID vs. name/slug), which matters given the resolve_organization sibling exists precisely to map names to identifiers.

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 (get an organization) plus a scope for the payload (3GPP participation summary), which tells an agent this returns participation data rather than raw org metadata. It is clear on its own, but it never distinguishes itself from the sibling resolve_organization, which plausibly serves a related org-lookup need.

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 when-to-use guidance and no mention of alternatives such as resolve_organization, which an agent might reasonably pick instead when it only holds an org name. The phrase 'one organization's' weakly implies a single-org lookup but gives no preconditions or exclusions.

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?

Discloses behavior well beyond the readOnlyHint/destructiveHint annotations: one-request-per-clause quota accounting, a pre-read 402 failure when quota is insufficient, per-clause status handling for missing clauses (nearest_sections), the 2,000-word excerpt cap with truncation flags, and provenance/available_before semantics. This is the kind of context an agent cannot derive from 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 core action, then organized under bold headers (Quota, Excerpt limit, Dates for prior art). It is dense and slightly long, but nearly every sentence carries behavioral detail that would otherwise be invisible.

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 and annotations cover the safety profile, yet the description still explains return shape (statuses, sub-clauses, truncation) sufficiently for correct invocation. Nothing an agent needs to call this batch tool 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 baseline is 3, but the description adds genuine semantics: the version-then-release-then-newest fallback chain, that available_before applies uniformly to every clause, and that results follow request order with per-clause statuses. This goes beyond restating 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 ('Read'), resource ('clauses'), and scope ('up to 10 in one call, from one or several documents'). The batching scope implicitly distinguishes it from the single-clause sibling get_sections_sections_get without needing to name it.

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 quota paragraph tells the agent the cost is identical to calling get_sections once per clause, which is useful decision context, but there is no explicit statement of when to prefer this batch call over the single-clause sibling or when-not to use it. Usage is only implied.

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?

The annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds a genuinely useful behavioral fact not in structured data: results are returned as 'short excerpts', warning the agent that the full clause text may be truncated and that another call or tool may be needed for complete text.

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 with no filler; the scope constraint ('specific sections') and the output-shape caveat ('short excerpts') are both delivered immediately.

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-value detail is not required, annotations cover safety, and all 7 parameters are documented in the schema. The one remaining gap is that it does not route the agent to get_sections_batch for multi-section retrieval, which would be a natural exclusion to state.

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 parameter docs are unusually rich (version inheritance, prefix sub-section behavior, available_before date semantics), so the schema carries the burden. The description adds no parameter-level information beyond it, which matches the baseline 3.

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 (Read) and resource (text of specific sections of a specification), which clearly separates it from document-level siblings like get_document_documents or list_sections_sections_toc_get. It stops short of naming the closely related get_sections_batch, so a 4 rather than a 5.

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 by the resource: look up the text of a named section. There is no explicit statement of when to prefer this over get_sections_batch (multiple sections), list_sections_sections_toc_get (titles only), or the search tools, so the agent must infer the routing.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds that metadata and status are returned, which is modest extra value, but it says nothing about pagination or how the 'include' extras change the fetch 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?

A single tight sentence with the resource and scope front-loaded and zero filler. It is arguably too terse for a 4-parameter tool, but there is no wasted language.

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 no output schema, the description should carry more of the return-shape burden, yet it only says 'metadata and status.' The input schema is self-documenting and annotations cover safety, so the gaps are moderate rather than severe.

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 75%, and the schema itself richly documents include, text_offset, and max_text_chars (including an example and paging hint). The description adds no parameter meaning beyond that, so the baseline of 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 ('Get metadata and status for one TDoc by number'), and the scope (single TDoc, addressed by number) clearly differentiates it from list_tdocs and search_tdocs. It does not, however, address the near-identical sibling fetch_tdoc, so an agent cannot tell those two apart from the description 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?

No when-to-use guidance, no exclusions, and no mention of the alternative sibling fetch_tdoc. The only implied usage is 'you already have a TDoc number,' which 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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the returned field list, which is redundant given an output schema exists, and says nothing about ordering, pagination, or result-size 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?

A single front-loaded sentence with zero filler; the purpose and returned fields come first. Nothing needs trimming.

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 explained, and the schema documents filters thoroughly. Still missing is any statement about default behavior, result ordering, or how this list differs from the get/search siblings, which an agent needs to route 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?

Schema description coverage is 100% and the filter parameters carry very rich descriptions in the schema (notably available_before, which explains UTC cutoff semantics and indexing gaps). The description contributes no parameter meaning 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 ('List') and resource ('indexed 3GPP specifications') plus the fields returned (number, title, release, version). It is distinguishable from the singular get_document_documents by the plural/list framing, but the description never explicitly contrasts itself with that sibling or with search_tdocs.

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 when-to-use statement, no mention of when a filtered list is preferable to search_tdocs/search_text, and no note on defaults (e.g. does an unfiltered call return all indexed specs?). Usage must be inferred purely from the name and schema.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's only added behavior is the implicit user-scoping ('signed-in user'), which is useful but minimal; it says nothing about result ordering, pagination, or volume.

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 eight-word sentence, front-loaded with the verb and resource. Nothing extraneous.

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-parameter list tool with annotations covering safety, the description is adequate but thin: with no output schema, an agent gets no signal about what a returned 'topic' looks like or whether results are paginated. A brief note on return shape or ordering would close the 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate at the parameter level, and it correctly implies no filtering options exist.

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 (topics), with a useful scoping qualifier: 'the signed-in user follows.' This distinguishes it from sibling find_topics_to_follow (discovery) and follow_topic/unfollow_topic (mutation), though it doesn't name those siblings 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?

No when-to-use guidance, no exclusions, and no pointer to related siblings like get_followed_topic_updates or find_topics_to_follow. An agent must infer from the name alone that this is the read side of the follow lifecycle.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not mention the default exclusion of 'noted' decisions, pagination via cursor/limit, or that results are scoped to one meeting — behavioral facts an agent needs and that only the schema hints at.

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 well-formed sentence with no filler, front-loading the operation and its scope. However, its brevity comes at the cost of the operational detail the tool actually needs.

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 7-parameter, paginated, filterable read tool with no output schema, the description is too thin. It never mentions the pagination loop, the default decision-type filter, or how the filters combine, leaving the agent to reconstruct behavior from the schema alone.

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 71%, and the description supplies no parameter meaning at all. It does not explain q's semantic matching, agenda_item's prefix behavior, the 50/200 limit bounds, cursor continuation, or the fact that decision_type defaults to everything except 'noted' — leaving the description unable to compensate for the 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 clear verb (List) and resource (meeting decisions), and enumerates the outcome categories — agreed, approved, noted, rejected — so an agent knows it returns decision records rather than raw meeting content. It does not distinguish itself from siblings like get_meeting or list_documents, which may also surface meeting outcomes.

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 guidance on when to choose this tool over alternatives such as get_meeting, nor any prerequisite or exclusion information. The agent must infer usage entirely from the name and schema.

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=true, openWorldHint=false and destructiveHint=false, so safety is covered externally; the description contributes no additional behavioral context. It does not say what happens when all filters are omitted (all meetings returned?), how results are ordered, or how large the result set can be — relevant because zero parameters are required.

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 with no filler, which is appropriate for a simple list endpoint. It is terse rather than padded, though the terseness edges toward under-specification rather than elegant brevity.

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 four-parameter, fully-documented read-only list tool with no output schema, the description is minimally viable: the schema carries parameter detail and annotations carry the safety profile. What is missing is disambiguation from the many sibling list/get tools and any note on unfiltered result behavior, which an agent needs 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?

Schema description coverage is 100%, so each parameter (group, since, until, state) is already documented with format and semantics. The description's 'by group and date' only echoes two of the four filters and omits state entirely, so it adds nothing beyond the schema. 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 ('List 3GPP working group meetings') and scopes it to group and date, which distinguishes it from the singular sibling get_meeting. It does not, however, acknowledge list_meeting_decisions or clarify how it differs from the other list_* tools in the family.

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 when-to-use guidance and no alternatives named. An agent cannot tell from the description whether to call this or get_meeting for a single meeting, or how this relates to list_meeting_decisions. Usage is only implied by the verb 'List'.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing behavioral beyond that: no note on ordering, pagination, or how much of the TOC is returned. With annotations doing the work, the description is purely a purpose restatement.

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 with no waste. It is efficient, though the brevity contributes to the missing sibling and usage context rather than being a virtue in itself.

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 full parameter coverage, the description needn't explain return values, so the remaining gap is narrower. However, in a namespace crowded with list_sections/get_sections siblings, one clarifying sentence about scope would materially help; its absence keeps this at minimum viable.

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 both parameters (doc_number, version) are well documented in the schema with examples. The description adds no additional parameter meaning, 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: retrieving the table of contents for a specification. It clearly identifies the operation, though it never distinguishes this from close siblings such as get_sections_sections_get or get_sections_batch, leaving the agent to infer the boundary between 'TOC' and 'sections'.

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 when-to-use guidance is provided. Nothing states when to pick this over get_sections_sections_get (full sections) or get_sections_batch, so the agent has no signal for choosing among the three related tools except a guess at naming.

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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered structurally. The description adds nothing behavioral: no pagination semantics, no note that withdrawn TDocs are excluded by default, no indication of result volume or ordering.

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 short sentence is front-loaded and waste-free, which is good. But the brevity here reflects under-specification rather than disciplined concision: a 15-filter tool is described with only two of its capabilities, so the sentence is too thin to be genuinely concise.

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 15-parameter, zero-required filter/search surface with no output schema, the description omits the bulk of the tool's behavior (free-text search, source/company resolution, status/doc_kind/work_item filters, date ranges, cursor paging) and gives no sense of return shape. It is not adequate for the tool's complexity.

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 every filter is already documented in the schema; the baseline of 3 applies. The description adds no parameter meaning beyond the two filters it names ('meeting', 'agenda item'), which the schema itself documents in more detail.

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 verb (list) and resource (TDocs), so the basic purpose is clear. However, 'for a meeting or agenda item' falsely implies those are the scoping parameters when the schema exposes 15 optional filters (source, spec, status, doc_kind, work_item, dates, free-text q, etc.), and it does nothing to distinguish this from the sibling search_tdocs or list_documents_documents_get.

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?

Provides no when-to-use guidance, no mention of when to prefer search_tdocs, and no stated prerequisites. The phrase 'for a meeting or agenda item' hints at a context but never explains how it differs from the other listing/search siblings.

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The word 'match' implies fuzzy resolution returning candidate organizations rather than an exact hit, but the description does not confirm ranking, scoring, or how multiple candidates are returned.

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 with no filler; every word earns its place. It is arguably too terse for a tool whose main ambiguity is sibling selection, but there is no structural waste.

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 low-complexity read-only lookup with full schema coverage, the definition is minimally viable. What is missing is the behavioral context an agent needs to call it correctly: whether results are ranked candidates, what a no-match looks like, and why to choose this over get_organization.

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 both parameters are documented in-schema, including examples for 'q' and the 1-25 bound for 'limit'. The description adds no format or syntax detail beyond the schema, 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 (match) and both ends of the transformation (company name -> 3GPP member organization), which is far more informative than the title's restatement. It does not name or contrast itself with the closely related sibling get_organization, so the differentiation is left implicit.

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 guidance on when to use this versus get_organization, which appears to retrieve an organization directly. The description also omits when-not-to-use conditions and any hint that inputs may be aliases or approximate names.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context of its own — nothing about ranking, latency, result mixing, or cost of the combined search — so it clears the lower bar set by annotations but adds no extra value.

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, purpose first, usage condition second, with zero filler. Nothing can be trimmed without losing routing 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 15-parameter tool with an output schema and full schema-level documentation, the description's job is narrow: state what it searches and when to pick it over the text-only or image-only siblings. It does the first well and the second adequately, leaving only explicit sibling routing unaddressed.

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 every parameter carries a detailed inline description (rerank, deduplicate, available_before semantics, match counts). The description adds no parameter guidance, so the baseline of 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+resource and a clear scope: 'Search specification text and figures together.' The word 'together' distinguishes it from the sibling text-only and image-only search tools, though it does not name them 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?

'Use when a question may be answered by a diagram or a clause' gives a concrete triggering condition that separates this from a plain text search. It stops short of naming the alternatives (search_text_search_text_post, search_images_search_images_post) or stating when to prefer them.

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=true and destructiveHint=false, so the safety profile is covered externally. The description adds the useful behavioral fact that results are figure captions plus their source sections, but says nothing about ranking behavior, thresholds, or pagination beyond what the schema documents.

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 tight sentences with the purpose front-loaded and no filler. It is efficient, though it is arguably under-specified rather than truly concise for an 8-parameter tool.

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 annotations cover safety. However, for a tool with 8 parameters spanning series, release, doc number, and an upload-date cutoff, the description leaves the whole filtering model and its sibling relationship unexplained.

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% across all 8 parameters, including rich per-parameter docs for deduplicate, available_before, and the filters, so the baseline is 3. The description only echoes the 'by description' notion already captured by the query parameter and adds no syntax or semantics 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 specific verb+resource ('Search figures and diagrams in 3GPP specifications by description') and adds the return shape (figure captions and source sections). The resource is narrow enough to distinguish it from text search at a glance, but it never names the sibling search tools it overlaps 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?

No when-to-use, when-not-to-use, or alternative guidance is given. With siblings like search_text_search_text_post and search_combined_search_combined_post in the list, an agent has no stated basis for choosing image search over those; it must infer solely from the word 'figures'.

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=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds only the vague 'indexed by Scout' framing and says nothing about pagination, result limits, total counts, or what an unfiltered search returns.

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 with zero waste. It is efficient, though arguably under-specified rather than concise given the tool's eight-parameter surface.

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 eight optional parameters, no output schema, and no required arguments, the description should explain what happens when no filters are supplied, how results are paged or ordered, and how this corpus relates to the sibling search endpoints. None of that is present.

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 75% with concrete examples and enumerated topic/source values for query, topic, source and company, so most semantics live in the schema. The description adds nothing for parameters, and limit/offset remain undocumented beyond min/max/default, but the baseline of 3 applies when the schema carries the weight.

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 ('Search telecom industry news'), with the added scope that results come from a corpus 'indexed by Scout.' It does not differentiate from siblings like search_tdocs or search_combined, so an agent cannot tell from the description alone which search corpus to pick.

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 guidance on when to use this tool versus the many sibling search tools (search_tdocs, search_positions, search_combined), and no mention of prerequisites or exclusions. The agent is left to infer usage entirely.

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=true, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds nothing behavioral beyond that — no indication of result shape, ordering, or how stances map to companies.

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 with no waste or filler. It is arguably too terse for a 6-parameter tool, but structure and economy are strong.

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 6-parameter search tool with no output schema, one sentence is thin: it omits how results relate to companies/stances, whether filtering by org or meeting narrows scope, and when to prefer the sibling get_company_positions. An agent can call it, but not confidently.

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 83%, so the schema already documents orgs, group, query, stance, and meeting with examples and enum-like values. The description adds no parameter meaning over the schema, which is the expected baseline at this coverage level.

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 ('Find') and resource ('which companies argued for or against a proposal'), making the semantic purpose clear. However, it never distinguishes itself from siblings like get_company_positions or search_tdocs, which a name like 'search_positions' invites confusion 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?

No when-to-use guidance, no exclusions, and no mention of alternatives such as get_company_positions or search_tdocs despite many overlapping siblings. The agent must infer usage purely from the one-line purpose.

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=true/openWorldHint=false, so the safety profile is covered; the description usefully states the return shape (spec number, version, section, short excerpt). It adds little beyond that, but since an output schema exists, that is acceptable rather than a 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 plus a quoted example, with purpose front-loaded and zero filler. Every sentence carries information an agent needs.

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 a rich schema, full annotations, and an output schema, the description only needs to convey scope and intent, which it does. It omits pagination/result-size expectations, but the schema's match_count/rerank_top_k fields largely cover that.

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 schema is unusually detailed (rerank, deduplicate, match_count, filters, etc.), so all parameter meaning is already carried. The description contributes nothing param-specific; 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+resource (search 3GPP specification text) and qualifies it as semantic ('by meaning'), which separates it from metadata-searching siblings like search_tdocs. It does not explicitly name search_combined_search_combined_post, so the boundary with the most similar sibling is left to inference.

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 example '"what does TS X say about Y"' implicitly frames the use case and is genuinely helpful, but there is no explicit when-to-use/when-not guidance or named alternative for keyword or metadata lookups.

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 destructiveHint=true and readOnlyHint=false, but the description adds important context beyond that: it deletes the follow from the user's account and the action cannot be undone. It still does not mention auth requirements or rate limits, but the irreversibility disclosure is valuable.

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 with zero waste. The core action is front-loaded and the irreversible consequence follows immediately, making it easy to parse quickly.

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 one-parameter destructive tool with annotations covering the safety profile, the description covers the action and irreversibility. However, it omits any guidance on the required follow_id, which is a notable gap given the schema provides no parameter description.

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% and the sole parameter follow_id has no description. The tool description says nothing about what follow_id is or where to obtain it, so it fails to compensate for the schema 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 states a specific verb+resource ('Stop following a topic') and adds the consequence ('delete it from the user's account'), clearly distinguishing it from siblings like follow_topic and update_followed_topic. An agent can identify the core action 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?

No when-to-use guidance or alternatives are provided. The description does not mention prerequisites, where the follow_id comes from, or how this relates to update_followed_topic or list_followed_topics, leaving usage entirely implied by the name.

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 destructiveHint=true and readOnlyHint=false, and the description adds the key operational detail that it 'Overwrites the previous settings' – clarifying that this is a replacement rather than a merge. It stops short of saying which fields are optional or whether omissions clear existing values.

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 tight sentences with the core action front-loaded and the destructive caveat second. No filler, though the brevity contributes to the parameter gaps.

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 5-parameter mutation with no annotations beyond safety hints and no output schema, the description is too thin: it omits the status/delivery parameters, doesn't clarify partial-update semantics, and gives no success/error behavior.

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 carry the burden, yet it only gestures at three concepts ('name, targets or digest settings') against five parameters. The status enum ('active'/'paused'), the delivery enum ('email'/'dashboard'), and the required follow_id are all left unexplained.

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 (Change) and resource (a followed topic) plus the affected fields (name, targets, digest settings). It reads clearly against siblings like follow_topic and unfollow_topic, though it doesn't explicitly differentiate itself from them.

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 when-to-use guidance, no mention of prerequisites, and no indication of how to obtain the required follow_id (e.g., via list_followed_topics). The sibling list is the only hint that this is the edit counterpart to follow_topic.

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