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

With no annotations, the description must carry the burden. It states the core behavior (creating an event) and adds that add_google_meet auto-generates a Meet link. However, it omits other behavioral aspects like permissions, invite side effects, or return value expectations.

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

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

Two sentences, front-loaded with the action, and every sentence provides useful details. No fluff or redundancy.

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 9-parameter tool with 3 required params and zero schema descriptions, this description is inadequate. It covers only datetime and Meet link behavior, leaving most parameters undocumented. The output schema exists, so returns needn't be described, but parameter coverage is too sparse.

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. It clarifies start/end formats (RFC3339 vs YYYY-MM-DD) and the add_google_meet flag, but leaves summary, location, timezone, attendees, calendar_id, and description unexplained. Only 2 of 9 parameters receive added meaning.

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 clearly states 'Create a calendar event', which is a specific verb and resource. It distinguishes from update/delete but not from the similar sibling calendar_quick_add, which also creates events.

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 is provided on when to use this tool versus alternatives like calendar_quick_add or calendar_update_event. The description only gives parameter formatting instructions, not context for tool 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 provided, the description carries the full burden of behavioral disclosure. It states the action 'Delete a calendar event' but does not mention whether the deletion is permanent, whether it affects the entire series or only instances, or any side effects. This is a significant gap for a destructive operation.

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 description is a single, concise sentence with no unnecessary words, which is structurally fine. However, it is so brief that it omits critical information, making it under-specified rather than effectively 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 destructive tool with no annotations and an output schema, the description is incomplete. It does not explain the implications of deletion, such as irreversibility, effects on recurring events, or what the response contains. An agent would have insufficient information to use this tool safely and 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 schema description coverage is 0%, meaning the schema provides no explanations for event_id or calendar_id. The tool description adds no parameter details, such as how to obtain an event ID or what calendar_id defaults to. The description fails to compensate for the lack of schema descriptions.

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 uses the specific verb 'Delete' and identifies the resource as 'a calendar event,' making the tool's function immediately clear. It also distinguishes itself from sibling tools like calendar_update_event and calendar_get_events by clearly targeting a delete operation.

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, no mention of exclusions or prerequisites, and no indication of scenarios where deletion might be inappropriate (e.g., recurring events or events shared with others). It simply states the action without any usage 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?

With no annotations, the description carries the full burden. It discloses the key behavior of returning busy time blocks and uses 'Query' to imply a read-only operation. However, it lacks additional context such as timezone handling, default calendar selection, or whether free blocks are also returned, leaving significant behavioral details unspecified.

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 description is very short and front-loaded with the main action. However, the second sentence ('Returns busy time blocks') partially restates the first, and the description could add useful details without becoming verbose. It is appropriately concise but slightly 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?

The tool has 4 parameters and an output schema, but the description provides minimal guidance on invocation. It lacks parameter syntax, how calendars are chosen when null, and details about return format. An agent would need to infer too much from the schema alone, making the description incomplete.

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 needed to compensate. It does not explain time_min/time_max format, timezone defaults, or the semantics of the calendars array. Param names provide minimal insight, but timezone and calendars require elaboration that is absent.

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 clearly states the operation ('Query') and the resource ('free/busy info for calendars'), and notes it returns busy time blocks. This distinguishes it from sibling calendar tools like calendar_get_events or calendar_create_event, making the purpose 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?

The description implies use for checking calendar availability, but it does not explicitly specify when to prefer this over calendar_get_events or calendar_list_recurring_instances. No alternatives or exclusions are mentioned, so guidance is only implicit.

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 burden of disclosure. It communicates the filtering behavior and RFC3339 time format, but does not mention default calendar behavior, result limits, or interaction of filters. These are minor gaps for a read-only operation.

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 description is two concise sentences, front-loaded with the main purpose and then filter options. There is no unnecessary content or repetition.

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 description covers the core retrieval and filter functionality but lacks important context about default calendar ID, max_results behavior, and how filters combine. An output schema exists, but the description could still be more complete for a tool with five parameters.

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

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

The input schema provides zero description coverage, so the description must compensate. It explains time range (RFC3339) and text search, which clarifies time_min, time_max, and query. However, calendar_id and max_results are left unexplained, leaving a partial 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 clearly states the tool's function with the verb 'Get' and resource 'calendar events', and specifies filtering by time range and text search. This distinguishes it from siblings like calendar_create_event and calendar_list_calendars.

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 usage for retrieving calendar events with optional filters, but it does not explicitly mention when to use this tool over similar read tools like calendar_freebusy or calendar_list_recurring_instances. No alternatives or exclusions are provided.

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 must carry the burden. It conveys that the tool is a read-only operation and that only calendars the user has access to are included. However, it does not disclose potential behavioral details like output structure or pagination. The qualifier 'has access to' adds useful context, but more could be said about return format.

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 description is a single concise sentence that conveys the essential purpose without any fluff. Every word adds meaning, and the sentence structure is clear and front-loaded.

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

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

Given the tool's simplicity (no parameters, no nested objects) and the presence of an output schema, the description is largely sufficient. It clearly defines what the tool does and its scope. It doesn't mention alternatives, but that's a minor omission for a basic listing operation.

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 has zero parameters, so per the rubric, the baseline is 4. The description adds no parameter information, but none is needed. The schema is empty and fully covered, so there is no 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 precisely states the action ('List all calendars') and the scope ('the user has access to'). It is unambiguous and distinguishes itself from sibling tools like calendar_get_events, which focus on events rather than calendar metadata.

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 usage: to retrieve a list of accessible calendars. However, it does not explicitly state when to use it over alternatives, nor does it mention any exclusions or prerequisites. For a simple listing tool, the implication is clear enough, but it lacks direct 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but offers no details about pagination, time range handling, or other behavioral traits. The description is too minimal to ensure the agent fully understands the tool's 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 description is a single, focused sentence: 'List instances of a recurring event.' Every word earns its place, with no unnecessary filler or repetition. This is an excellent example of concise, front-loaded writing.

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?

Despite having an output schema, the description is insufficient for a tool with five parameters and no annotation support. It does not explain what constitutes a 'recurring event instance,' how time_min/time_max filter results, or the role of calendar_id and max_results. The tool is simple, but the description leaves too much unsaid for confident invocation.

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 schema has 0% description coverage for parameters, and the tool description does not compensate by explaining any of the five parameters. Parameter names like event_id and time_max are somewhat self-explanatory, but the description adds no semantic value beyond the schema, leaving unclear how parameters interact or are formatted.

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 'List instances of a recurring event' uses a specific verb and resource, clearly conveying the tool's function. It does not explicitly differentiate from sibling tools like calendar_get_events, but the focus on 'recurring event instances' distinguishes it effectively.

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 calendar_get_events. It simply states what the tool does, leaving usage context entirely to the agent's 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?

No annotations are provided, placing the full burden on the description. It doesn't mention that events go to the 'primary' calendar by default, how parsing errors are handled, whether authentication is needed, or any other behavioral traits beyond the basic creation. The example is helpful but insufficient.

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 description is a single sentence with a concrete example. Every word earns its place, and the structure is front-loaded with the primary action and parameter behavior.

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 relatively simple with only two parameters and an output schema that covers return values. However, the natural language parsing behavior is underspecified, and the lack of annotation/behavioral detail leaves gaps for an agent deciding whether to invoke this 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?

With 0% schema description coverage, the description must compensate. It partially does for 'text' via the example, but the optional 'calendar_id' parameter is completely undocumented in both schema and description, leaving its semantics unclear.

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 clearly states the tool creates a calendar event, and the 'natural language' phrase plus example distinguishes it from the structured calendar_create_event sibling. However, it doesn't explicitly name the alternative or contrast with 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 natural language aspect implies when to use this tool (quick, friendly input) but there is no explicit guidance about when to prefer calendar_create_event or any exclusions. The usage context is inferred rather than stated.

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 must carry the behavioral disclosure burden. It discloses that only provided fields are changed (a partial-update semantic), which is useful. But it omits other behavioral aspects like permissions, error conditions, or how clearing a field is handled, and gives no context on defaults like timezone or calendar_id.

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, followed by a precise behavioral qualifier. No filler words.

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 mutation tool with 8 parameters, no annotations, and no parameter description coverage, this description is under-specified. It doesn't address time formats, default calendar behavior, or how to unset fields, though the presence of an output schema reduces the need to document return values.

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?

Input schema has 8 parameters with 0% description coverage. The description doesn't name or explain any specific parameter; 'provided fields' is a generic reference that doesn't clarify formats, defaults, or relationships. For example, start/end format and timezone semantics are undocumented.

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 uses the specific verb 'Update' with the resource 'calendar event' and scopes it to 'existing' events, clearly distinguishing this from calendar_create_event and calendar_delete_event. The phrase 'Only provided fields are changed' further defines its partial-update purpose.

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 explicit when/when-not or alternative tool names are given. However, the word 'existing' implies this is for modifying current events rather than creating new ones, and the partial-update note implies usage guidance. This is implied but not explicit.

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 provided, the description bears full responsibility for disclosing behavior, yet it only restates the action "create" which is already evident from the name. It fails to mention side effects, error handling, atomicity, batch limits, or required permissions, providing no meaningful behavioral transparency.

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 description is one sentence that front-loads the action and immediately provides a compact inline schema for the input. It is free of unnecessary words and every element contributes useful information.

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

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

The tool is relatively simple and the input structure is described, but operational context is missing, such as batch size limits, behavior on partial failures, and whether the operation is atomic. The presence of an output schema means return values need not be detailed, but other behavioral gaps remain, leaving the description minimally adequate.

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 schema provides no descriptions for the contacts array items (0% coverage), so the description adds value by listing expected fields: "{givenName, familyName, email, phone, organization, title}". However, it does not specify data types, required vs. optional status, or formats, offering only partial compensation 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 clearly states the tool's function: "Create multiple contacts at once." It specifies the verb (Create), resource (contacts), and scope (multiple), effectively distinguishing it from the sibling tool contacts_create for single contact creation. The preview of the contact dict structure adds further clarity.

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 batch usage with the phrase "multiple contacts at once," but it does not explicitly contrast with contacts_create or state when not to use this tool. No alternatives are mentioned, so usage guidance relies on inference rather than explicit direction.

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 must carry the burden of behavioral disclosure. It only states 'Delete' without mentioning permanence, irreversibility, auth requirements, partial-failure behavior, or response implications. For a destructive operation, this is a significant 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for such a simple tool, though it could include slightly more detail without harming conciseness.

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?

A destructive batch delete operation with no annotations and zero parameter documentation is under-specified. Even though the output schema exists and the parameter count is low, the description fails to provide essential context such as the shape of resource_names or safety notes, making the tool risky to invoke 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 schema description coverage is 0%, yet the description does not explain what 'resource_names' means (e.g., format like 'contacts/123' vs simple IDs). The parameter name provides a hint, but without additional detail, an agent may not know what values to pass.

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 'Delete multiple contacts at once' has a specific verb+resource and clearly distinguishes from the sibling tool 'contacts_delete' by emphasizing 'multiple' and 'at once.' It unambiguously states what the tool does.

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 use when deleting multiple contacts, but it does not explicitly contrast with 'contacts_delete' or provide when-not-to-use guidance. The batch context is implied but not formalized.

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 provided, the description carries the full burden of disclosing behavior, but it only restates the mutation intent. It does not mention required permissions, idempotency, behavior on duplicate contacts, or what the response contains, which is a significant gap for a create operation.

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 description is a single, front-loaded sentence that directly states the action and lists fields. It is appropriately concise with no wasted words, though it could have used the space to clarify required fields or parameter specifics.

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

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

Given the tool has 6 parameters, 0% schema description coverage, and no annotations, the description is insufficient. It omits family_name, does not clarify the required given_name, and provides no context on contact creation behavior, uniqueness, or relationship to batch operations, making it difficult for an agent to use correctly without external knowledge.

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 explain the parameters. It mentions 'name' (which is ambiguous between given_name and family_name), email, phone, organization, and title, but omits family_name entirely. 'Title' is also ambiguous (job title vs. honorific), and no formats or constraints are clarified.

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 clearly states the action ('Create a new contact') and lists the key fields (name, email, phone, organization, title), making the purpose understandable. However, it does not differentiate from sibling tools like contacts_batch_create, which also creates contacts.

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 is provided on when to use this tool instead of alternatives such as contacts_batch_create, contacts_update, or contacts_search. There are no usage conditions, prerequisites, or exclusions mentioned, leaving the agent without context for tool 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 provided, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning permissions, idempotency, duplicate handling, side effects, or any other behavioral traits that would help the agent anticipate the consequences of invoking the 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?

The description is a single, direct sentence with no unnecessary words. It is front-loaded with the verb and object, making it immediately readable. For a simple one-parameter creation tool, this conciseness is ideal.

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?

Although an output schema exists, the description lacks essential contextual information: no usage guidelines, no behavioral details, and no constraints or prerequisites. For a tool with zero annotations, the description is insufficient to give the agent a complete understanding of when and how to use it safely and 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 input schema has 0% description coverage for the 'name' parameter, and the description does not mention or explain the parameter at all. While the parameter name is relatively self-explanatory in the context of creating a group, the description adds no semantic meaning or usage hints beyond the schema field itself.

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 uses a specific verb ('Create') and resource ('contact group'), clearly stating the tool's function. It distinguishes from sibling tools like contacts_create (likely for contacts) and contacts_list_groups, making the purpose 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?

The description provides no guidance on when to use this tool versus alternatives, lacks exclusions, and does not mention prerequisites or typical use cases. The usage is left entirely to inference from the tool name and description, which is minimal.

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 of behavioral disclosure. It only states the deletion action but does not mention that deletion is permanent, irreversible, or any side effects. The description adds no context beyond what the tool name already implies, leaving the agent without critical safety information.

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 description is a single sentence that is concise and front-loaded. It avoids unnecessary words and communicates the core purpose effectively. Every word earns its place.

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 delete operation with one parameter, the description is minimally adequate. The tool has an output schema which likely explains return values, so not describing them is acceptable. However, it lacks information about irreversibility and any permissions required, which is important for a mutation tool without 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?

The input schema has 0% description coverage, but the description's phrase 'by resource name' adds meaning to the single parameter, resource_name. This indicates that the parameter identifies the contact to delete. However, it does not clarify the format or how to obtain the resource name, leaving some ambiguity.

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 clearly states the action (delete) and the target resource (a contact), and specifies how the target is identified (by resource name). This distinguishes it from sibling tools like contacts_batch_delete, which operates on multiple contacts. The verb is specific and 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?

The description provides no guidance on when to use this tool versus alternatives. While the name implies single contact deletion, it does not explicitly mention when to use contacts_batch_delete for multiple contacts or any other contextual cues. There is no mention of prerequisites 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns a photo URL, but it does not mention edge cases such as missing photos, error conditions, or required permissions. This is minimally sufficient for a simple read operation but lacks depth.

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 description is a single, front-loaded sentence with no filler or redundancy. It communicates the tool's core purpose efficiently and is appropriately sized for a simple getter 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?

The tool is simple, has one parameter, and an output schema exists to document return values. However, the description lacks input semantics and usage guidance, so an agent may not know how to construct resource_name. It is adequate for basic selection but not fully complete for reliable invocation.

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 input schema has zero description coverage for resource_name, and the tool description only says 'for a contact,' implying the parameter identifies a contact but not how the string should be formatted or where it comes from. Since schema coverage is 0%, the description should compensate but does not provide enough parameter-level 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?

The description uses a specific verb ('Get') and resource ('photo URL for a contact'), making the tool's purpose immediately clear. It also distinguishes this tool from sibling contacts tools like contacts_search, contacts_list, and contacts_update, as it is the only one focused on photo retrieval.

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 this tool should be used when you need a contact's photo URL, but it provides no explicit guidance on when to use it versus alternatives or how to obtain the required resource_name (e.g., via contacts_search or contacts_list). The usage context is only implied, not fully explained.

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 states the behavior (listing all contacts, sorted by last name) but omits the effect of the max_results parameter, which can limit the number returned. This is a notable behavioral gap, as an agent might assume 'all' always means the complete list, not just up to 50.

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 description is a single, concise sentence that front-loads the key information. There is no wasted verbiage, and it is easily scannable.

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?

Although a simple tool, the description is incomplete because it omits the impact of max_results on the result set. The output schema likely covers return structure, but the parameter's limiting behavior is essential for correct invocation. Without it, the tool may return unexpected 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 schema has one parameter (max_results) with 0% description coverage. The description does not even hint at this parameter or its purpose. Since schema coverage is zero, the description fails to compensate and leaves the parameter ambiguous.

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 clearly states the action ('List'), the resource ('contacts'), and the scope ('all contacts'), with a specific sort order ('by last name'). This distinguishes it from sibling tools like contacts_search, which presumably filters, and contacts_list_groups, which lists groups rather than contacts.

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 is given about when to use this tool versus alternatives. There is no mention of 'use this when you need the full contact list' or 'for searching, use contacts_search.' The only implied usage is that it lists all contacts, but no explicit exclusions or alternatives are provided.

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 of behavioral disclosure. It only states 'List all contact groups (labels)' and provides no details about pagination, the max_results parameter, whether the list is ordered, or any side effects. While 'list' implies a read operation, the description lacks substantive behavioral context.

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 description is a single, concise sentence that immediately conveys the core action and resource. There is no redundant information, and the structure is clear and efficient for a simple utility.

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?

While an output schema exists and the tool is relatively simple, the description omits critical contextual information such as how max_results behaves, whether all groups are returned, or how this relates to other group-management tools. This leaves gaps for an agent deciding on invocation and interpreting 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 schema includes a max_results parameter with a default of 50, but the description does not explain its meaning, acceptable values, or effect on results. Since schema description coverage is 0%, the description should compensate, but it does not mention any parameter details.

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 clearly states the tool's action ('List') and resource ('all contact groups'), and even clarifies that groups are also called 'labels'. It is distinct from sibling tools like contacts_list and contacts_search, which operate on individual contacts rather than groups.

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 is provided on when to use this tool versus alternatives. There is no mention of related tools like contacts_create_group or contacts_modify_group_members, nor any context about typical use cases such as retrieving a group overview before assigning contacts.

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 must carry the full burden of behavioral disclosure. It only says 'add or remove contacts' without explaining side effects, idempotency, permissions, or how existing members are affected. For a mutation tool, this is a significant 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?

The description is a single concise sentence with no wasted words. It is front-loaded with the action and appropriately sized, even though it is sparse in content.

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

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

Given the tool's complexity (3 parameters, mutation, no annotations), the description is too sparse. It doesn't explain operation semantics, input expectations, or edge cases, and it fails to compensate for the lack of schema descriptions. An output schema exists, but the description still leaves critical unknowns.

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. It only hints that contacts are added/removed and that a group is involved, but it doesn't explain parameter formats, mutual exclusivity, or requiredness. The parameter names are self-explanatory, but the description adds little beyond them.

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 clearly states the tool's function: 'Add or remove contacts from a contact group.' It uses specific verbs and a specific resource, and it distinguishes from sibling tools like contacts_create_group or contacts_update. The name and description are well-aligned.

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 guidance on when to use this tool instead of alternatives. It lacks prerequisites, exclusions, or references to sibling tools like contacts_batch_create/delete. The usage context is entirely implied, not stated.

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 for behavioral disclosure. It only states the search criteria and omits details about result format, pagination, case sensitivity, or how multiple fields are combined. The max_results parameter is not mentioned in the description, leaving the agent guessing about result limits.

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 that succinctly conveys the tool's purpose without unnecessary words. It is appropriately sized for a simple search operation.

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 description gives the essential purpose and query semantics, and the output schema covers return values. However, it lacks usage guidelines and behavioral details, and with no annotations, the sparse description leaves notable gaps for an AI agent to fully understand the tool's invocation and expected 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?

The description adds meaning to the 'query' parameter by specifying it matches name, email, or phone number, which goes beyond the bare schema label. However, it does not explain the 'max_results' parameter, leaving a gap for one of the two parameters in a schema with 0% description coverage.

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 clearly states the tool searches contacts by name, email, or phone number, using a specific verb and resource with search criteria. However, it does not explicitly differentiate from sibling tools like contacts_list, which could also serve a similar lookup purpose.

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 is provided on when to use this tool versus alternatives like contacts_list or when not to use it. There are no explicit exclusions or recommended contexts.

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 must explain behavioral traits. It only says 'Update a contact' without disclosing whether the update is partial or full replacement, whether omitted fields are preserved, or any permission requirements. Minimal behavioral disclosure.

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, no filler. The key information (resource name source) is placed early and efficiently. Structure is ideal for a tool description.

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

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

Given it is a mutation tool with no annotations and a 0% schema description coverage, the description is too thin. It lacks update semantics (e.g., partial vs. full), which is critical for safe use. The output schema exists but does not compensate for the missing behavioral context.

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. It only adds meaning for resource_name, explaining its provenance. The other six parameters (email, phone, etc.) rely solely on their titles and are not elaborated in the description.

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 clearly states the action: 'Update a contact.' The verb 'update' distinguishes it from sibling tools like contacts_create and contacts_delete. It also specifies the resource source, which makes the purpose unmistakable.

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 explicitly instructs that the resource name must come from contacts_search or contacts_list, giving clear context on how to obtain the required identifier. It does not mention exclusions or alternatives, but the usage context is clear enough.

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 provided, the description carries the full burden of disclosing behavior, but it only states the action without explaining side effects, formatting behavior, or whether it modifies the document structure. There is no mention of how appended text integrates with existing content.

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 description is a single concise sentence with no filler words, making it easy to parse. It is appropriately sized for the tool's simplicity.

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 mutation tool with no annotations and multiple similar siblings, the description is underspecified. It lacks usage differentiation and behavioral context, though the existing output schema may cover return values.

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 schema description coverage is 0%, and the description does not elaborate on the parameters. It does not clarify document_id format or the expected text content, leaving the agent without additional semantic context beyond the parameter names.

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 clearly states the action ('Append text') and target ('end of a Google Doc'), providing a specific verb and resource. However, it does not distinguish this from sibling tools like docs_append_paragraph or docs_insert_text, which perform similar operations.

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 choose this tool over alternatives. It simply states the operation without any context, exclusions, or references to sibling tools.

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 mentions core behavior (creates a doc, optional initial text) but does not disclose side effects like Drive storage, authentication needs, or that it returns a document ID. For a simple create operation, this is borderline 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?

The description is a single, concise sentence that is immediately front-loaded with the key verb and resource. Every word adds value, with no unnecessary filler or redundant detail.

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 2-parameter creation tool with an output schema, the description covers the essential action and optional parameter. It does not mention that the doc is created in Drive or any prerequisites, but given the tool's simplicity, this is reasonably complete.

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. It clarifies that body_text is optional and serves as initial content, but it does not explicitly explain the title parameter (though that is self-evident from the schema property name). It adds some value but not comprehensive parameter documentation.

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 clearly states the action ('Create'), the resource ('a new Google Doc'), and an optional scope ('with optional initial text content'). This distinguishes it from siblings like docs_append_text or drive_create_file, which modify or create other file types.

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 usage for creating a new Google Doc, but provides no explicit guidance on when to prefer this over related tools, no exclusions, and no alternative tool mentions. The context from sibling names helps, but the description itself lacks direct usage clarity.

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 provided, the description needs to explain the tool's behavior but only states the basic action. It does not disclose whether all occurrences are replaced, case sensitivity handling, direct modification of the document, or any side effects, which is a significant gap for a mutation 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?

The description is a single, concise sentence with no filler. It is front-loaded with the core action and effectively sized for a reading agent.

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 tool with 4 parameters, no annotations, and a basic description, the operation is under-specified. It lacks important context about how the replacement behaves or any prerequisites, though the existence of an output schema somewhat reduces the need to explain return values.

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 should compensate by explaining parameters. The description only implies find_text and replace_text via the phrase 'find and replace text' but does not clarify match_case or document_id. It adds minimal value beyond the parameter names themselves.

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 clearly identifies the tool's function: finding and replacing text in a Google Doc. It uses a specific verb and resource, and it distinguishes itself from sibling tools like docs_insert_text or docs_format_text by focusing on the find-and-replace action.

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 alternatives or when not to use it. The description simply states the operation, leaving the agent to infer the appropriate context without any exclusions or alternative recommendations.

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 must disclose mutation effects. It only says 'Apply formatting' without explaining that it modifies existing text, whether formatting is overwritten or merged, what happens with invalid indices, or that it requires an authenticated document. This is a significant lack of transparency for a mutating 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?

The description is a single sentence that is front-loaded with the key action and scope. Every word is necessary, and there is no redundancy.

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

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

Given 9 parameters and no annotations, the description is too sparse. It does not address parameter semantics beyond naming formatting types, nor does it provide usage context. The presence of an output schema covers return values, but the description remains incomplete for a tool of this 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?

The schema has 0% description coverage. The description identifies the formatting attributes (bold, italic, underline, font size, color) that correspond to parameters, but it omits strikethrough and does not explain the meaning of start_index/end_index (e.g., zero-based, exclusive end) or the color format. It adds some semantics but leaves critical parameter details ambiguous.

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 clearly states that this tool applies inline formatting (bold, italic, underline, font size, color) to a specified text range in a Google Doc. It distinguishes this from sibling tools like docs_set_paragraph_style (paragraph-level) and docs_set_alignment (alignment).

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 alternatives. It does not mention that this is for character-level formatting or that docs_batch_update might be more appropriate for multiple changes. No exclusions or prerequisites are stated.

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 exist, so the description carries the full burden. It does not disclose behavioral traits such as whether existing bullet formatting is replaced or toggled, how start_index and end_index map to paragraphs, or any side effects. The description only states the action without contextual detail.

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 description is a single concise sentence with no fluff. It is efficiently structured and front-loaded, but the brevity comes at the cost of omitting necessary details for correct usage.

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 tool with 4 parameters, no annotations, and no output schema shown, the description is too thin. It fails to explain parameter meanings, bullet_type options, or the expected behavior when applying formatting to a range. The description is not sufficient for an agent to use the tool effectively.

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 schema has 0% description coverage, and the tool description provides no parameter semantics. It does not explain that start_index and end_index refer to character offsets, what bullet_type accepts (beyond a default value), or the role of document_id. The description adds no value for parameter understanding.

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 clearly states the tool's function: 'Apply bullet or numbered list formatting to paragraphs in a Google Doc.' It uses a specific verb and resource, distinguishing it from sibling tools like docs_insert_paragraph (which inserts new paragraphs) and slides_insert_bullets (which works on slides).

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 is provided on when to use this tool versus alternatives like docs_set_paragraph_style or docs_format_text. The description implies usage for list formatting but does not state when it should be preferred or excluded.

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. It only states the primary function and does not disclose key behaviors such as URL accessibility requirements, default placement, whether the image is embedded or linked, or what happens on invalid URLs. This is a significant gap for a mutation 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?

The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it sacrifices informativeness for 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?

Given the complexity of the tool (inserting an image into a specific document with size and positioning parameters) and the lack of annotations or schema descriptions, the description is insufficient. It does not explain placement semantics, prerequisites for the URL, or how the index parameter affects behavior. The presence of an output schema does not compensate for these gaps in selection and invocation guidance.

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. It mentions 'from a URL' which sheds light on image_uri, but it does not explain document_id, index, width_pt, or height_pt. Most parameter meanings remain opaque, requiring the agent to guess or use defaults without clear guidance.

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 clearly states the specific action (insert), the resource (image), the destination (Google Doc), and the source (URL). This distinguishes it from sibling tools like docs_insert_text or slides_insert_image.

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 this tool (when inserting an image from a URL into a Google Doc) but provides no explicit alternatives or exclusions. It does not differentiate from similar insert tools in other services (e.g., slides_insert_image) or other docs inserts.

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 provided, the description carries the full burden of behavioral disclosure. It only states 'Insert a page break' and does not explain the meaning of the 'index' parameter, any side effects on existing content, or permission requirements. The tool is a mutation but lacks detail.

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 description is one sentence with zero wasted words, making it appropriately concise for a simple tool. However, it is under-specified, which slightly detracts from its effectiveness.

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 simple, but the description omits critical context about the 'index' parameter, such as whether it is 0-based or 1-based and what happens to surrounding content. Even though an output schema exists, the input semantics remain incomplete.

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 for the undocumented parameters. However, the description does not mention 'document_id' or 'index' at all, leaving their semantics completely 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?

The description clearly states the tool's function with a specific verb and resource: 'Insert a page break in a Google Doc.' It distinguishes itself from sibling tools like docs_insert_paragraph and docs_insert_text by naming the exact action (page break).

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 other insert operations. There are no mentions of alternatives, prerequisites, or scenarios where this tool is preferred.

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 provided, the description carries the full burden of disclosing behavioral traits. It only states the action (inserting a table) without mentioning insertion position via the 'index' parameter, size constraints, or effects on existing content. It does not contradict annotations, but it is far too sparse.

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 description is a single, direct sentence with no wasted words. It is appropriately front-loaded and concise for the basic action it describes.

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 mutation tool with 4 parameters and no annotations, the description is seriously incomplete. It lacks parameter explanations, insertion behavior, and usage guidance. An agent would not have enough information to invoke it correctly beyond guessing from the tool name and 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?

The input schema has 0% description coverage, and the tool description adds no clarification for any parameter. While 'rows' and 'columns' are somewhat self-explanatory, 'index' remains ambiguous (default 1 but unclear if it's a 1-based position). The description fails to compensate for the schema's lack of 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?

The description uses a specific verb ('insert') and a specific resource ('table') with a clear target ('Google Doc'), making it distinct from sibling tools like docs_insert_paragraph and docs_insert_image. It immediately conveys the tool's core function.

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 usage context is implied: use this tool to insert a table into a document. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it differentiate from closely related tools like docs_insert_table_row or docs_add_table (if present).

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 must carry the full burden of behavioral disclosure. It explains the 1-based indexing behavior, which is useful, but does not mention side effects like shifting existing content or that this is a mutation. It is not misleading, but incomplete for a tool with no annotation coverage.

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

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

Two sentences with no wasted words. The description is front-loaded with the primary action and includes the essential indexing detail. Ideal for a simple 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?

For a tool with only 3 simple parameters and an output schema, the description provides sufficient context for correct invocation. It lacks details like format of inserted text, but these are not critical for the tool's straightforward purpose. Slightly above minimum viability.

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. It explains the 'index' parameter semantics (1 = beginning), but does not explicitly explain 'text' or 'document_id', though their meanings are obvious from their names. Partial compensation for a simple parameter set.

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 clearly states the action (insert text) and the target resource (Google Doc), with a specific modifier ('at a specific position') that distinguishes it from siblings like docs_append_text. The index base clarification ('Index 1 = beginning') adds precision.

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 this tool (when insertion at a specific position is needed) by contrasting with append/paragraph tools, but it does not explicitly name alternatives or exclusion conditions. The context is clear enough for an agent to select it appropriately.

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 word 'Read' implies a non-destructive operation, and 'full text content' indicates the return format. However, without annotations, the description does not disclose permissions, size limits, or error behavior beyond this basic indication.

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 description is a single, focused sentence with no redundancy.

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 an output schema, the description provides sufficient functional clarity. It lacks usage context but is otherwise complete for basic selection and invocation.

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 description does not mention the document_id parameter or its meaning. The schema provides only the parameter name and type without description, leaving the agent to infer that document_id is the Google Doc's 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 'Read the full text content of a Google Doc,' providing a specific verb (read), resource (Google Doc), and scope (full text content). This clearly distinguishes it from sibling tools that modify or search docs.

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 is given on when to use this tool versus alternatives like drive_read_file or docs_find_replace. The description merely states what it does without contextual or exclusionary information.

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 bears full responsibility for disclosure. It does not mention potential side effects, permission requirements, irreversibility, or whether the operation is a mutation, leaving the agent without critical behavioral context.

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 description is a single, succinct sentence with no redundant words. It is front-loaded, directly stating the action and target, making it highly scannable.

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?

While the tool has an output schema and only two parameters, the description lacks context about file types, user permissions, or relation to other Drive tools. Combined with absent annotations and minimal parameter info, the overall context is insufficient for an agent to invoke the tool 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 0%, and the description does not explain the parameters file_id or content. The agent is left to infer from parameter titles alone, with no additional meaning provided about their format, purpose, or constraints.

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 clearly states the action ('Add a comment') and the resource ('a Drive file'), providing a specific verb and object. However, it does not explicitly distinguish itself from sibling tools like drive_list_comments, though the action difference is inherent.

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 alternatives, nor any prerequisites or exclusions. The description simply states what it does without contextualizing its use relative to other Drive comment tools.

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 of behavioral disclosure. It only states 'Copy a file,' without detailing whether this creates a new copy, the role of optional name/folder_id, side effects, or return value. This is minimal but not entirely missing, as the action 'copy' implies duplication.

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 description is a single, short sentence with no unnecessary words. It is front-loaded and perfectly concise for the simple action it describes.

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 has three parameters, no annotations, and an output schema, yet the description is extremely sparse. Given the complexity, the description is not complete enough: it fails to explain parameter semantics, usage context, or expected behavior. The output schema may cover return values, but the description still leaves significant 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?

The description adds no meaning beyond the input schema. With 0% schema description coverage, the agent has no idea what 'name' or 'folder_id' actually do. The description does not compensate for the undocumented parameters at all.

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 uses a specific verb 'Copy' with a clear resource 'a file in Google Drive.' It clearly distinguishes from sibling tools like drive_read_file, drive_create_file, or drive_share_file by specifying the copy action. The purpose is immediately clear and 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it duplicates a file, explain how it relates to drive_move or drive_create, or provide any exclusions or prerequisites. This leaves the agent without context for 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?

No annotations are provided, so the description must carry the full burden of disclosing side effects, permissions, and behavior. It only states that a file is created and mentions the as_google_doc flag, with no information about defaults, overwriting behavior, error conditions, or access requirements.

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 description is two short sentences with no filler, front-loading the purpose and adding one useful hint. It is appropriately brief.

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

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

Given the lack of annotations, 0% parameter documentation, and a complex ecosystem of sibling create tools, the description is far too minimal to give an agent everything it needs to invoke correctly. It lacks usage context, parameter details, and behavioral expectations.

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 schema has 0% description coverage for its 5 parameters. The description adds meaning for as_google_doc by explaining its effect, but it leaves name, content, folder_id, and mime_type unexplained, which is insufficient given the low schema coverage.

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 clearly states 'Create a new file in Drive' with a verb and resource, and adds a specific hint about as_google_doc. However, it does not explicitly differentiate from sibling create tools like drive_create_folder or docs_create, so it is clear but not fully distinguishing.

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 like drive_create_folder, docs_create, sheets_create, or drive_copy_file. The only hint is setting as_google_doc=True, but it does not explain when that is preferred over using docs_create directly.

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 of behavioral disclosure. It only says 'Create a folder' without mentioning permissions, parent folder behavior, naming conflicts, or side effects. This is a significant gap for a mutation 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?

The description is a single, direct sentence with no filler. It front-loads the core action and uses words efficiently, matching the 'zero waste' standard.

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?

Despite having only 2 parameters and an output schema, the description is too minimal. It omits details about the parent folder, default behavior, return values, and prerequisite conditions (e.g., permissions), which are necessary for correct invocation.

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% (0% of parameters are described in the schema), and the description provides no additional meaning for 'name' or 'parent_id'. The description fails to compensate for the lack of schema documentation.

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 clearly states the verb ('Create') and the resource ('a folder in Google Drive'), distinguishing it from sibling tools like drive_create_file. It is specific and 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?

There is no guidance on when to use this tool versus alternatives, such as drive_create_file for files or drive_list_folder for listing. No exclusions or alternative suggestions are mentioned.

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 description discloses that this is a destructive action (removing a permission) but provides no additional context such as irreversibility, ownership requirements, or impact on file access. Since no annotations are present, the description carries the full burden and falls short of disclosing behavioral traits beyond the basic operation.

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 description is a single, direct sentence that states the core function without any unnecessary words or fluff. It is front-loaded and appropriately concise for the tool's simple purpose.

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 delete operation, the description is functional but lacks important context such as how to obtain the permission_id (e.g., via drive_list_permissions) or any caveats about ownership or failed deletions. The presence of an output schema reduces the need to explain return values, but the description still feels incomplete for a mutation 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?

The schema provides no descriptions for its parameters (0% coverage), and the description does not compensate by explaining the roles of file_id and permission_id. While the parameter names are self-explanatory, the description adds no meaning beyond what the schema field names already imply, so it fails to bridge 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 clearly states the action 'Remove' and the object 'a sharing permission from a file', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like drive_share_file (adds permission) and drive_list_permissions (lists permissions).

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 explicit guidance is provided about when to use this tool compared to alternatives. The use case is implied by the name and description, but there is no mention of prerequisites, such as needing to list permissions first to obtain the permission ID, or any 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?

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the primary action and does not mention that the original file is left unmodified, required permissions/scopes, or the limitation that the file must be a native Google Workspace file. This is a significant transparency 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?

The description is a single, front-loaded sentence with no fluff. Every word contributes to the core purpose, making it easy to parse and memorable.

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 are defined elsewhere. For a simple 2-parameter tool, the description covers the basic purpose and format options, but lacks parameter-specific instructions and usage constraints, making it only adequately complete.

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. It provides human-readable format examples (PDF, DOCX, etc.) that hint at the mime_type parameter, but it does not explicitly map parameter names to their roles or specify actual MIME type syntax (e.g., 'application/pdf'). Partial guidance only.

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 explicitly states the action ('Export') and the target ('a Google Workspace file to a format'), and the format examples (PDF, DOCX, CSV, etc.) make the scope clear. This distinguishes the tool from sibling tools like drive_read_file or drive_copy_file.

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

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

The description clearly implies when to use the tool: when a file needs to be converted to a different format. However, it does not explicitly mention alternatives or exclusions, such as when drive_read_file might be more appropriate for reading raw content.

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 full responsibility for behavioral disclosure. It only states 'list comments' without mentioning that it is a read-only operation, any pagination behavior, auth requirements, or return format. The description adds no behavioral context beyond the basic action.

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 description is a single concise sentence, front-loaded with the action, with no redundant words. It earns its place.

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 listing tool, the description is functional but lacks important context about ordering, pagination, or how to interpret results. Given that an output schema exists (not shown), return values needn't be described, but the absence of usage guidance and parameter semantics leaves gaps. It is minimally adequate.

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. While 'on a Drive file' implicitly identifies the file_id parameter, the max_results parameter is completely unexplained (no mention of pagination, defaults, or limits). The description adds minimal meaning beyond the bare 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 uses a specific verb 'list' and resource 'comments on a Drive file', clearly distinguishing it from sibling tools like drive_add_comment or drive_list_revisions. It accurately states the tool's function.

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 is provided on when to use this tool versus alternatives like drive_read_file or drive_add_comment. The description lacks any context about appropriate use cases, prerequisites, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it discloses nothing beyond the basic action. It does not clarify whether listing returns immediate children only, includes subfolders, how pagination/max_results behaves, or what permissions are needed.

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 description is a single, front-loaded sentence with zero wasted words. It is appropriately concise for a simple tool, although it is sparse enough to border on under-specification.

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 covered elsewhere. However, the description leaves behavioral gaps—recursive vs. immediate listing, inclusion of files vs. subfolders, and max_results semantics—making it minimally viable with clear 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 description coverage is 0%, and the description fails to compensate by explaining folder_id or max_results. Although the parameter names and defaults in the schema are reasonably self-explanatory, the description adds no meaning beyond the bare function statement.

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 uses a specific verb ('List') with a clear resource ('contents of a Drive folder'), precisely stating the tool's function. The verb and resource distinguish it from sibling tools like drive_search (searching across Drive) and drive_read_file (reading a file's content).

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 usage guidance, offering only a bare statement of function. It does not mention when to use this tool versus alternatives like drive_search, nor does it state any prerequisites 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?

No annotations are provided, so the description carries the full burden. It only states the action without disclosing behavioral traits such as whether it is read-only, what permissions are returned (e.g., users, groups, public access), or any side effects. This is minimal transparency.

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 description is a single, clear sentence with no wasted words. It is appropriately sized for a simple listing operation.

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 has a single parameter and an output schema, so the description does not need to explain return values. However, it lacks any guidance on usage, prerequisites, or what 'sharing permissions' encompasses, making it minimally adequate but incomplete in context.

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 description does not explain the file_id parameter. It adds no meaning beyond the field name, failing to compensate for the schema's lack of description.

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 uses the specific verb 'List' with the resource 'sharing permissions on a file', clearly stating the action and scope. It distinguishes the tool from siblings like drive_share_file and drive_delete_permission by focusing on reading permissions rather than modifying 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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing the file_id, or any comparison with related tools like drive_share_file or drive_delete_permission. The description simply states the action without 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List file revisions' without mentioning what is included (e.g., metadata, timestamps), pagination, sorting, or whether it is a read-only operation. Minimal behavioral detail is provided.

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 description is a single, concise sentence that is front-loaded and contains zero wasted words. It efficiently communicates the core action and resource.

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 simple with one required parameter, and an output schema exists, reducing the need to explain return values. However, the lack of any usage guidelines or behavioral context makes the description only minimally viable for an AI agent deciding when and how to invoke it.

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 description does not explicitly describe the file_id parameter. However, the phrase 'List file revisions' implies that file_id identifies the file whose revisions are listed, adding marginal meaning beyond the schema's bare parameter name and type.

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 clearly states a specific verb 'List' and resource 'file revisions' with the clarifying parenthetical 'version history'. It distinguishes itself from sibling tools like drive_read_file or drive_search, as no other sibling targets revision history.

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. It only states what the tool does, without any context, prerequisites, or exclusions, leaving the agent to infer usage from the name and sibling tools.

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 provided, the description carries the full burden. It does disclose that Google Docs/Sheets/Slides are exported and that raw text files are read directly, which adds useful behavioral context. However, it does not mention limitations (e.g., unsupported binary formats like PDFs) or any error behavior, which is a notable gap for a read 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?

The description is a single, concise sentence that front-loads the primary action and scope. Every word is functional, with no fluff or repetition.

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 tool with only one parameter and an output schema present, the description adequately covers the core functionality. It explains the input (a Drive file) and the output (text content). It lacks detail on edge cases like unsupported file types, but overall it is sufficiently complete for a simple read operation.

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. It neither explains what 'file_id' refers to nor provides examples or format hints. While the parameter name is self-explanatory, the description adds no specific meaning beyond the schema's 'string' type, leaving ambiguity about where to obtain a valid ID.

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 uses a specific verb ('Read') and resource ('text content of a Drive file'), and clearly specifies the scope: Google Docs/Sheets/Slides exported, or raw text files. This distinguishes it from sibling tools like drive_export (which exports files) and drive_copy_file (which copies).

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 clear context on when to use the tool (when you need the text content of a Drive file), and it disambiguates from file export or copying. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.

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 provided, the description carries the full burden. It discloses the use of Drive query syntax, which hints at metadata-based searching (e.g., 'name contains', 'mimeType'), but it does not explicitly state limitations (e.g., no full-text content search) or permissions requirements. It adds some useful behavioral context but lacks depth.

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 description is a single, front-loaded sentence followed by concise examples. It contains no wasted words and efficiently communicates the tool's purpose and key usage detail (query syntax).

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 tool with two parameters and an output schema, the description covers the essential behavioral aspect (query syntax) and does not need to explain return values. However, it lacks explicit usage guidance vs alternatives and does not mention the max_results parameter, leaving slight incompleteness for an agent.

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 description significantly clarifies the 'query' parameter by providing syntax examples, which is crucial given the 0% schema description coverage. However, it completely ignores 'max_results', leaving its meaning and usage to be inferred from the schema's default value. Thus, it partially compensates for the missing schema descriptions.

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 clearly states 'Search Google Drive files', which uses a specific verb and resource. It distinguishes from sibling tools like drive_list_folder (which lists folder contents) and drive_read_file (which reads a specific file) by focusing on searching with query syntax. The examples of query syntax further clarify its purpose.

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 usage for searching files via Drive query syntax, but it does not explicitly contrast with alternatives like drive_list_folder or provide when-to-use/when-not-to-use guidance. There are no exclusions or direct references to sibling tools, so the usage context 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?

No annotations are provided, so the description carries the full burden. It only says 'Share' without explaining that this modifies the file's permissions, may send notifications, or has other side effects. The role list is useful but not behavioral.

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 no filler. Front-loaded with the action, followed by the role list. Every word is useful.

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?

Despite having an output schema, the description lacks context about side effects, prerequisites, or when to use this tool versus alternatives. It is minimally viable but leaves significant gaps for a mutation 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 0%, so the description must compensate. It adds semantics for 'role' by listing allowed values, but does not explain 'file_id', 'email', or 'send_notification'. The parameters are largely undocumented.

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 clearly states the action ('Share a Drive file') and resource, with a specific list of roles. This distinguishes it from sibling tools like drive_delete_permission or drive_list_permissions.

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 vs alternatives (e.g., drive_delete_permission). No mention of context, prerequisites, 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?

The description discloses the core behavior ('move to trash') but nothing beyond that. With no annotations, it does not mention reversibility, permissions, or side effects. However, the action itself is transparent, and the sibling drive_untrash implies recoverability.

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 description is a single, concise sentence with no filler, front-loading the action and destination. Every word earns its place.

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 single-parameter operation, the description provides the essential action. However, it lacks any contextual guidance about when to use trash versus other file operations, and it does not mention the output schema (though that is provided separately).

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 schema provides only the file_id parameter with no description, and the tool description does not elaborate on it. With 0% schema coverage, the description must compensate but does not explain the parameter's format, scope, or requirements, leaving the agent to infer from the name.

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 clearly states the tool's function with a specific verb ('Move') and resource ('a file'), and the destination 'trash' distinguishes it from sibling tools like drive_untrash. It directly answers what the tool does.

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, nor any exclusions or alternatives mentioned. The description only states what it does, not when to prefer it over other file operations, so the agent gets no contextual help.

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 provided, the description carries the full burden of behavioral disclosure. It only states the obvious action (restore) without revealing any side effects, permission requirements, or behavior concerning file location. This is minimal and insufficient for a mutation 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?

The description is a single, front-loaded sentence with no fluff, but it is under-specified. While concise, it lacks essential context, making it less useful than a slightly longer but more informative description. It is not egregiously padded, hence a middle score.

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 tool with one parameter, no annotations, and a mutation side effect, the description is incomplete. It does not explain when to use the tool, what happens to the file after restoration, or any prerequisites. The presence of an output schema does not compensate for the missing behavioral context.

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 input schema has 0% description coverage, and the description does not mention the 'file_id' parameter at all. The schema only indicates it is a string, leaving its purpose entirely unexplained. The description fails to compensate for the lack of parameter documentation.

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 'Restore a file from the trash.' clearly states the action (restore) and the resource (file in trash). It is specific and easily distinguished from sibling tools like drive_trash, which performs the opposite action.

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 alternatives. The description does not mention conditions (e.g., file must be in trash), prerequisites, or exclusions, leaving the agent 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Add a question' and lists types, without mentioning side effects, required fields, or how the question is inserted (e.g., at the end by default). This is minimal and does not reveal any behavioral traits beyond the basic action.

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 description is very concise: two short sentences with no wasted words. The first sentence states the core action, and the second lists types, which is useful. However, it may be slightly under-specified, but as a conciseness measure, it is well-structured and front-loaded.

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

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

The tool has 7 parameters and no annotations, yet the description is only two sentences. It lacks critical context about how to specify choice options, where the question is inserted, the role of the 'required' flag, and what the output schema contains. This is completely inadequate for a tool with this 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 0%, so the description must compensate for the 7 parameters. It only lists valid question types, which maps to the 'question_type' parameter, but provides no explanation for index, options, required, paragraph, or how they interact. This adds minimal value over the raw 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 clearly states the action ('Add a question') and the resource ('a form'), making the primary purpose unambiguous. It lacks explicit differentiation from sibling tools like forms_update_question, but the verb 'add' versus 'update' provides enough distinction. The list of types adds useful context.

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 is given on when to use this tool versus alternatives such as forms_update_question or forms_move_question. The description does not mention any context, prerequisites, or exclusions, leaving the agent without clear decision-making support.

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 full responsibility for behavioral disclosure. It merely states the creation action without mentioning that it is a write operation, any permission requirements, side effects, or what the tool returns (e.g., the new form's ID). This lacks transparency for an agent.

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 description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple create operation, and every word contributes to the meaning.

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 description is too minimal to be contextually complete for a tool with no annotations and no parameter descriptions. It does not mention the initial state of the created form, its relationship to sibling tools, or any expected output beyond the implicit creation. The agent is left to guess too much.

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 description does not explain the 'title' or 'description' parameters. Although the parameter names are somewhat self-explanatory, the description adds no meaning about their roles, constraints, or defaults. It fails to compensate for the missing schema descriptions.

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 'Create a new Google Form' clearly states the action (create) and the resource (Google Form), and it distinguishes itself from sibling tools like forms_read or forms_add_question. The purpose is unambiguous and 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention that it is for creating an initial form shell, nor does it exclude scenarios like adding questions or updating settings. There is no context about prerequisites or recommended usage.

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 of behavioral disclosure. While 'Delete' implies destructiveness and the 0-based index detail is useful, the description does not mention permanence, side effects on other questions, or any other behavioral traits beyond the operation itself.

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 description is a single concise sentence that is front-loaded with the action and resource. It avoids verbosity, but the brevity veers toward under-specification, which is penalized in other dimensions rather than here.

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 destructive operation with no annotations and no parameter descriptions, the description is too sparse. It does not explain what happens after deletion, whether it can be undone, or what the response contains (though an output schema exists). The tool needs more context to be considered complete.

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. It adds meaningful semantics for item_index by specifying '0-based index', but it provides no explanation for form_id. With two parameters and coverage of only one, the compensation is partial at best.

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 uses a specific verb ('Delete'), identifies the resource ('a question from a form'), and adds a distinct detail ('by its 0-based index'). This clearly differentiates it from sibling tools like forms_add_question, forms_update_question, and forms_move_question.

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, nor any prerequisites or exclusions. It simply states what the tool does, leaving usage decisions entirely to the agent.

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 provided, the description carries the full burden of behavioral disclosure, but it only restates the basic function. It does not mention response format, pagination, default max_results behavior, or any side effects. The description adds no value beyond the tool name.

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 description is a single concise sentence that is easy to parse. However, it is under-specified, omitting crucial details about parameters and usage, so the brevity comes at the cost of completeness.

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?

While the tool is relatively simple and an output schema exists, the description is incomplete. It fails to mention the max_results parameter or clarify how 'all' reconciles with pagination. The missing annotations could have been compensated in the description, but were not.

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?

Input schema coverage in the description is 0% — it does not explain form_id or max_results. The schema itself provides minimal context (max_results default 50), but the description offers no additional meaning, failing to compensate for the lack of parameter documentation.

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 clearly states the tool lists responses from a Google Form, distinguishing it from sibling tools that read form structure or manage questions. However, the phrase 'all responses' is misleading given the max_results parameter with a default of 50, which implies pagination or limiting.

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 alternatives like forms_read, which might also access form data. The description does not mention exclusions, prerequisites, or scenarios where this tool is preferred.

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 provided, the description carries the full burden of disclosing behavior. It only states 'Move/reorder,' which implies mutation but does not explain index semantics, potential side effects, or whether the operation is reversible. No additional behavioral context is provided.

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 description is a single concise sentence that front-loads the core action and resource. There is no wasted text, making it highly efficient.

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 has 3 required parameters and no annotation support, yet the description is extremely brief. It does not cover index semantics, return values, or any edge cases. Even though an output schema exists, the lack of behavioral and parameter detail leaves the description incomplete for correct invocation.

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 description does not explain any of the parameters (form_id, from_index, to_index). While the parameter names are somewhat self-explanatory, the description adds no meaning beyond the schema and fails to compensate for the lack of schema descriptions.

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 uses a specific verb 'Move/reorder' and clearly identifies the resource 'a question in a form.' This distinguishes it from sibling tools like forms_add_question, forms_update_question, and forms_delete_question, making the tool's purpose 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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context such as needing a form ID or constraints on indices. It simply states the action without usage 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?

Without annotations, the description carries the full burden of behavioral disclosure. It only says 'Read', which implies a non-mutating operation, but adds no detail about permissions, limitations, or edge cases. It essentially restates the tool name without enriching behavioral context.

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 description is a single, concise sentence with no filler words. It is front-loaded with the action and clearly enumerates the three aspects of the form being read. Every word earns its place.

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 an output schema (which explains return values), the description adequately conveys what the tool does. It lists the specific elements (structure, questions, settings) that will be read, making it reasonably complete. Some context about access requirements is missing but not critical.

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 schema has 0% description coverage for the single parameter form_id. The description does not explain how to obtain or format the form_id, nor does it connect the mentioned 'structure, questions, and settings' to the parameter. It fails to compensate for the low schema coverage.

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 clearly states the tool reads a form's structure, questions, and settings, using the specific verb 'Read' and identifying the resource. This distinguishes it from sibling tools like forms_list_responses (which reads responses) and forms_update_settings (which modifies settings).

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 explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is only implied by the verb 'Read', which is insufficient for a tool with many 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Update' without mentioning permissions, reversibility, effects on unspecified fields, or error conditions. This is a significant gap for a mutation 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?

The description is a single sentence, which is concise, but it is under-specified for a tool with four parameters. No details about parameters or behavior are included, so it is not appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (4 params, mutation, output schema exists), the description is far too brief. It does not explain how to identify the question (item_index), what fields can be updated, or any behavioral implications. The presence of an output schema does not compensate for the lack of operational guidance.

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 by explaining parameters. It does not; it only says 'update an existing question,' leaving form_id, item_index, title, and required entirely unexplained. The schema itself lacks descriptions, giving the agent no guidance.

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 uses a specific verb ('Update') and a clear resource ('existing question in a form'), which clearly states the tool's function. It distinguishes from sibling tools like forms_add_question and forms_delete_question, though it does not explicitly name alternatives.

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 is provided on when to use this tool versus alternatives. The word 'existing' implies modifying a previously created question, but no explicit conditions, prerequisites, or exclusions are given.

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 provided, the description carries the full burden of behavioral disclosure. It only states that the tool updates settings but does not mention that this is a write operation, any potential side effects, permission requirements, reversibility, or how partial updates are handled. For a mutation tool, this is insufficient.

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 description is a single, efficient sentence that is front-loaded with the action and includes practical examples. It is appropriately concise for the tool's simplicity, though it could add a bit more behavioral context without becoming verbose.

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 a mutation operation with no annotations, no output schema details visible, and a brief description. Given the presence of siblings that modify forms (e.g., forms_update_question), the description lacks crucial context about the scope of 'settings', permissions, and how it fits into the broader form-management workflow. The minimal information may lead to incorrect tool selection or invocation.

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 input schema has 0% description coverage, so the description must compensate. It explains two parameters (is_quiz as 'make it a quiz', description as 'change description') but completely omits the required form_id parameter. It also does not clarify update semantics (e.g., whether null values leave existing settings untouched), leaving ambiguity.

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 clearly states the action ('Update form settings') and gives concrete examples ('make it a quiz, change description'), distinguishing it from sibling tools like forms_add_question or forms_update_question. The verb+resource combination is specific and 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?

The description implies when to use this tool (when updating form-level settings) but provides no explicit when-not-to-use or alternative tool references. The examples of quiz and description help infer usage context, but there is no guidance on exclusions or prerequisites.

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