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

No annotations are provided, so the description carries full behavioral disclosure burden. It reveals that the tool performs mutations (WRITE), warns about unreliable temp-id maps, and advises against retrying. This goes beyond basic schema info, though it does not cover other traits like idempotency or atomicity.

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 extremely concise and front-loaded with 'WRITE.' Every sentence adds value: the operation list, the note about POST, and the crucial warning. No redundancy or filler.

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

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

Given the presence of an output schema, the description does not need to detail return values, but it does warn about the id-map unreliability. However, it does not fully describe the input parameter format, which is critical for a tool with only one parameter. The warning is helpful but the incomplete parameter documentation limits completeness.

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 schema description coverage at 0%, the description must compensate. It lists the operation types but does not explain the required structure of the JSON array or the fields for each operation. This leaves the agent with insufficient detail to construct valid input.

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 'WRITE' and 'Apply graph edits', listing all supported operations. It distinguishes from graph_records by noting that records are created via edits, not via a separate POST endpoint.

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

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

Provides explicit guidance on when to use: to apply graph edits. The warning about retrying when no temp-id map is present gives clear post-invocation behavior, and suggests reading back with graph_records to reconcile. However, it does not explicitly state when not to use this tool.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions the mandatory filter requirement and the behavior of the 'expand_relationships' parameter (walks edges). However, it does not disclose auth requirements, rate limits, error behavior beyond rejection, or any other side effects, which leaves gaps in 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 two sentences long, front-loaded with the purpose, and contains no filler. Every sentence provides essential information.

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

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

An output schema exists, so return value details are not required. The description covers the key constraint (mandatory filter) and optional behavior (expand relationships). It misses explaining the 'max_records' parameter, but overall it is sufficient 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?

The schema description coverage is 0%, so the description must compensate. It adds meaning for 'type_name' (mandatory, filter) and 'expand_relationships' (walks edges), but does not address 'max_records'. Given the low parameter count, this partial coverage is adequate but not comprehensive.

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 verb 'Fetch' with a specific resource 'graph records' and clarifies that it operates on one type, with a reference to 'graph_types' for finding names. This clearly distinguishes it from sibling tools like graph_types and graph_edits.

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 explicitly states that a type filter is mandatory and that the API will reject unfiltered listings, citing a knowledge base reference. It also advises using 'graph_types' to find valid type names. This provides clear context for when to use the tool, though it does not explicitly state when not to use it or compare to alternatives.

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

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

No annotations are provided, so the description carries full burden. It correctly communicates a read-only list operation with no side effects. However, it does not disclose any additional behavioral traits such as authentication requirements or rate 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 with zero wasted words. Perfect conciseness 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?

Given zero parameters and an output schema (present), the description is largely complete. It could mention that the output is a list of names, but the context is sufficient for an AI agent to understand the tool's purpose.

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

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

Schema coverage is 100% with zero parameters, so the description needs no parameter details. The baseline of 4 applies as the description adds no value beyond the schema but also doesn't detract.

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 'List' and the resource 'graph record type names', unambiguously defining the tool's function. It is distinct from sibling tools like graph_records or kb_search.

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

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

No guidance on when to use this tool versus alternatives (e.g., graph_records). The description implies its usage context (workspace) but lacks explicit context 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 discloses that drafts are saved locally to ~/.workiva/kb/drafts/ and later promoted via PR, and explains parameter syntax. However, it does not describe behavior on duplicate entry_id or error cases.

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 concise and well-structured, front-loading the purpose and using bullet-like format for parameter details. It could be slightly tighter but is effective.

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 10 parameters and no schema descriptions, the description covers key aspects: when to use, parameter semantics, and the end-to-end workflow (local draft, human PR). It lacks some parameter guidance and output details, but overall is fairly 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?

With 0% schema description coverage, the description adds significant value by explaining entry_id format, severity options, symptom as search key, tags format, and api_version. However, it omits details for 5 parameters (title, problem, surface, evidence, resolution), leaving gaps.

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 purpose: 'Record a newly discovered Workiva quirk so nobody researches it twice.' It uses a specific verb ('record') and resource ('quirk'), and is distinct from sibling tools like kb_search (searching) and kb_list (listing).

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 guidance on when to use the tool: 'Add an entry whenever you lost more than a few minutes to something not obvious from the docs.' It implies not to use for trivial things and contrasts with read-only sibling tools, but does not explicitly state when not to use or list alternatives.

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

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

The description indicates a read operation ('retrieve') and specifies what is included ('in full, including evidence'), but does not disclose other behavioral traits such as idempotency, auth requirements, or error conditions. With no annotations, more detail would improve 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 concise sentence that immediately conveys the tool's core function. Every word adds value, no fluff.

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

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

For a simple one-parameter read tool with an output schema, the description provides sufficient context. It could mention prerequisites or error conditions, but the core purpose is clearly communicated.

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 parameter entry_id has 0% schema description coverage and the tool description does not explain its meaning or format. No additional semantics are provided beyond the schema's title 'Entry 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 clearly states the tool retrieves one KB entry in full including evidence, distinguishing it from siblings like kb_search (search) and kb_list (list) which return summaries.

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-to-use or when-not-to-use guidance is given. Usage is implied: use when you have an entry_id and need the full entry details. It lacks alternatives 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 must convey behavioral traits. It implies a read-only operation ('Reading all blocker entries') but does not explicitly state idempotency, side effects, or other behavioral details. This is adequate but not fully transparent.

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 with two sentences. The first sentence states the core functionality, and the second adds practical guidance. No redundant 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?

The description covers the tool's purpose, parameters, and a usage context. With an output schema available, the description does not need to detail return values. It could mention pagination or default behavior when no filters are given, but overall it is sufficiently complete for a simple listing 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 has 0% description coverage, so the description fully compensates by listing the allowed values for each parameter (surface: wdata, platform, graph, etc.; severity: blocker, gotcha, nuance). This adds essential meaning beyond the schema.

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

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

The description clearly states the action (List), resource (KB entries), and optional filters (surface, severity). It distinguishes from siblings like kb_search, kb_get, and kb_add by focusing on listing with specific filters.

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 provides a concrete use case: reading all blocker entries before planning Workiva work to avoid API dead ends. However, it doesn't explicitly contrast with kb_search or state when not to use this tool.

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

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

No annotations provided, so description carries full burden. It describes indexing on symptom strings and expected answers. Does not disclose limitations or side effects, but provides solid behavioral context for a knowledge search 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?

Description is moderately sized, front-loaded with main purpose. Sentences earn their place, though could be slightly tighter. Use of line breaks improves readability.

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 and presence of an output schema, the description provides sufficient context: when to use, what to pass, what answers to get. Missing explicit output format is offset by output schema. Complete enough for agent decision.

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

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

Schema coverage 0%, so description must compensate. It explains the 'query' parameter well (pass error text or task). However, 'limit' parameter is not mentioned; its default and purpose are left to schema. Partial but adequate for the critical parameter.

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

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

The description clearly states the tool searches accumulated Workiva API knowledge, with strong verb 'search' and specific resource 'Workiva API knowledge'. It distinguishes from siblings like kb_list and kb_get by emphasizing use for unfamiliar work and error recovery.

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?

Explicit instructions: use before attempting unfamiliar work and when calls fail unexpectedly. Guidance on what to pass (error text or task description) and what answers to expect. No alternatives named but context is clear.

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

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

No annotations are provided, so the description carries full burden. It mentions 'including any bound dataset,' which gives some insight, but lacks details on authentication, error handling, or behavior (e.g., what happens if spreadsheet_id is invalid).

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, concise sentence that front-loads the core action. Every word is necessary, with no filler.

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

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

Given the tool's simplicity (one required param, output schema exists), the description is minimally adequate. It captures the main function but could mention consequences or prerequisites (e.g., spreadsheet must exist). The output schema likely provides details, but the description leaves some uncertainty.

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

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

Only one parameter (spreadsheet_id) exists, and schema description coverage is 0%. The description adds no extra meaning beyond the schema title 'Spreadsheet Id.' While the name is self-explanatory, the description should provide context on valid values or expected format.

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 (List), the resource (sheets), and the scope (in a spreadsheet including bound datasets). It is unambiguous and distinguishes the tool from siblings like spreadsheet_update or spreadsheet_ui_url.

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

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

No guidance on when to use this tool versus alternatives. Sibling tools like wdata_list_tables may overlap conceptually, but the description offers no differentiation or 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?

No annotations are provided, so the description is the sole source of behavioral info. It discloses that the URL is constructed from workspace id (referencing a KB article) and defaults to the first sheet. This adds valuable context beyond the schema.

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 three sentences, front-loaded with the main action, followed by rationale and default behavior. Every sentence adds value without 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 tool with 2 parameters and no output schema, the description covers the purpose, construction method (KB reference), and default behavior. It could mention the return type (a URL string), but overall it is fairly 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%, but the description explains that sheet_id defaults to empty (first sheet) and the URL uses workspace id. The required spreadsheet_id parameter is not detailed, but its purpose is inferable from context. Some added meaning, but not comprehensive.

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 builds a Spreadsheets UI URL for a spreadsheet or sheet, with a specific verb and resource. It distinguishes from sibling tools like spreadsheet_list_sheets and spreadsheet_update.

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 mentions the URL is needed for the query-result export endpoint and human users, hinting at usage context. However, it lacks explicit guidance on when to use this tool versus alternatives like kb_search or spreadsheet_list_sheets.

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

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

Discloses that it is a write operation, waits for async completion, and has formatting constraints. Without annotations, the description carries the full burden and adequately conveys key behaviors.

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

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

Three concise sentences with no redundancy. Each sentence adds value: purpose and options, formatting tip, and async 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?

Given the presence of an output schema, the description does not need to detail return values. It covers the essential behavioral and usage aspects for a write 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 description adds meaningful context to operations_json by enumerating valid values and noting index behavior (0-based, inclusive). With 0% schema coverage, this compensates well, though spreadsheet_id and sheet_id lack added 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 explicitly states 'WRITE. Write to a sheet,' clearly identifying the verb and resource. It also lists the allowed operations (editRange, editCells, applyFormats, resizeColumns), distinguishing it from sibling tools like spreadsheet_list_sheets.

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 usage tips such as sending numbers as JSON numbers and referencing a KB article, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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 provided; description only states 'WRITE' and column format, lacking behavioral details like permissions or behavior on duplicates.

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?

Extremely concise, front-loads core purpose, and includes essential parameter guidance without wasted 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?

Adequate for a tool with output schema and KB reference, but lacks context on prerequisites or side effects for a write 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?

Adds value by explaining columns_json format and directing to KB, compensating for 0% schema description coverage; name and description remain 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?

Clearly states 'Create a Wdata table' with 'WRITE' prefix, distinguishing it from read/query siblings like wdata_list_tables and wdata_get_table.

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-to-use or alternatives, but 'WRITE' implies mutation and references KB for column types, providing some 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?

No annotations are provided, so the description carries full burden. It implies read-only behavior ('get') but does not explicitly disclose side effects, authentication requirements, or other behavioral traits. The description is minimal but not misleading.

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, well-structured sentence that front-loads the key purpose ('Full detail for one Wdata table'). No extraneous words; perfectly concise for the information it conveys.

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 presence of an output schema (which explains return values), the description is complete enough for a simple retrieval tool with one required parameter. It could mention that the table_id must be valid, but it is broadly 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 description does not add any meaning to the sole parameter 'table_id' beyond what the schema provides (a required string). Since schema description coverage is 0%, the description should clarify the parameter's format or origin, but it does not.

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 it returns full detail for one Wdata table, including its column schema. However, it does not differentiate from sibling tools like wdata_list_tables or other retrieval tools, which also operate on Wdata tables.

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 such as wdata_list_tables or any other related tools. The description lacks context about prerequisites (e.g., table must exist) or when other tools might be more appropriate.

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 provided, so description carries full burden. It discloses that the tool is read-only (cannot create connections) and references a KB for more context. It does not cover rate limits or error handling, but the key behavioral trait is well explained.

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?

Description is three sentences with clear front-loading: purpose, requirement, limitation. No redundant information; every sentence serves a 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?

Given the existence of an output schema (not shown), the description need not explain return values. It covers the essential function, required filters, and a key limitation. Could hint at pagination or result count, but overall 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 description must compensate. It explains the filter pair requirement and gives an example, but does not detail each parameter's allowed values (e.g., source_type options). The description adds value but is incomplete for full 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?

Description clearly states the tool lists 'Wdata connections' and explains they are 'live query -> spreadsheet links'. This verb+resource combination is specific and distinguishes from sibling tools like wdata_list_tables and wdata_list_queries.

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?

Explicitly states that a filter pair is REQUIRED (source_type+source_id or destination_type+destination_id) and provides an example. Also notes that connections cannot be created via API, which sets expectations and guides appropriate 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. It states it lists queries with id, name, and timestamp, implying a read-only operation. However, it does not explicitly confirm it is non-destructive or mention any access restrictions.

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 of 7 words. Every word is necessary and clearly communicates the action and key output fields.

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 0 parameters and an output schema available, the description is complete. It specifies the action and the returned fields, and the sibling list helps situate it among other Wdata tools.

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 no parameters, and the description adds no parameter information. However, with 0 parameters and 100% schema coverage, the baseline is 4, and the description does not detract from that.

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 clearly identifies the resource as 'saved Wdata queries', including the fields returned (id, name, updated timestamp). It distinguishes from sibling tools like wdata_list_tables (lists tables) and wdata_get_table (gets one table) by focusing on queries.

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. It does not state that this tool is for browsing query metadata, nor does it mention when to use wdata_run_saved_query or other related 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 must carry the full burden of behavioral disclosure. It does not mention any traits such as authentication requirements, rate limits, or whether the operation is read-only. While the tool's name suggests a read operation, the description does not confirm this or disclose any other behavioral aspects. This is a significant gap for a no-annotation scenario.

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 concise and well-structured: first sentence states what is listed, second sentence provides critical usage guidance. Every sentence adds value with no redundancy or fluff. It efficiently conveys all necessary information in two clear sentences.

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 no parameters and has an output schema, the description adequately explains the key output field sql_ref and its usage. However, it does not mention the scope of the list (e.g., all tables the user has access to) or any potential limits. It could be slightly more complete by noting that it returns all accessible tables, but for a simple list operation, the current description is nearly sufficient.

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 no parameters, so the dimension baseline is 4. The description adds no parameter semantics (none needed) but does explain the output fields, providing context that goes beyond the schema. Since there are no parameters to describe, a score of 4 is appropriate.

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

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

The description clearly states it lists Wdata tables and specifies the exact fields returned (id, name, databaseId, lastUploaded, sql_ref). This distinguishes it from sibling tools like wdata_get_table (which likely gets a single table) and wdata_list_queries (which lists queries). The verb 'list' 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 explicit usage instructions for the critical output field sql_ref: 'Copy sql_ref verbatim into your query: SELECT ... FROM <sql_ref> AS "alias"'. It also explains that databaseId doubles as workspace id in Spreadsheets UI URLs. However, it does not explicitly state when to use this tool vs alternatives (e.g., when to use wdata_get_table instead), though this is implied by the tool's purpose. The guidance is valuable but could be more explicit about 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?

No annotations provided, so description must carry burden. It notes 'WRITE' (mutation), 'wait for it to settle' (asynchronous), and 'updates in place'. However, it lacks details on auth requirements, error handling, timeout consequences, or side effects beyond the basic 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?

Very concise: three sentences, front-loaded with 'WRITE.' No superfluous words. All information is relevant and 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?

Output schema exists but not described. Parameter details missing. For a tool with no annotations and 100% schema coverage gap, the description is minimally adequate but leaves important gaps about return values and parameter specifics.

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%, but description does not explain the two parameters: connection_id and timeout. Only the tool's action implies connection_id is needed. Timeout is not mentioned at all. Description fails to compensate for lacking 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?

Description clearly states the tool refreshes an existing connection and updates spreadsheet data in place. It specifies the resource (connection) and action (refresh, wait). It also distinguishes from creation by stating connections can only be refreshed via API.

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

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

Provides clear prerequisite: 'Find connection ids with wdata_list_connections'. Notes that connections cannot be created via API, implying when to use this tool (refresh only). However, it does not explicitly compare to sibling tools or state when not to use it.

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 fully disclose behavior. It states 'execute' and 'return rows' but fails to mention whether the operation is read-only, has side effects, or how it handles long-running queries (despite a timeout parameter). The output schema exists but is not described.

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 efficiently conveys the core purpose and references a sibling tool. It is concise, though restructuring to separate the parenthetical reference could slightly improve readability.

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 parameters and no annotations, yet the description is too minimal. It does not explain return value format, pagination (max_rows), timeout behavior, or prerequisites. The output schema may cover some details, but the description should provide a high-level overview.

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 explain parameters. It only mentions 'by id' (query_id), leaving timeout and max_rows unexplained. The agent has no guidance on the meaning or impact of these crucial parameters.

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 (execute), resource (saved Wdata query by id), and result (return rows). It references the sibling tool wdata_list_queries to find query ids, distinguishing it from similar tools like wdata_run_sql.

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 implicitly indicates use when you have a saved query id and want to execute it, and references wdata_list_queries to obtain ids. However, it does not explicitly mention when not to use it (e.g., for ad-hoc SQL use wdata_run_sql) or provide alternatives beyond the brief reference.

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 description carries full burden. It transparently reveals the internal mechanics: creates a temporary saved query, runs it, downloads CSV, then deletes it. Discloses side effects and the lack of ad-hoc SQL endpoint. This is excellent 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?

Three sentences: purpose, critical constraint, mechanics. Front-loaded, no fluff. Every sentence adds value.

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?

Covers purpose, table naming, dialect, and behavioral mechanics. Output schema documents return values, reducing need here. Could mention defaults for timeout/max_rows but not critical. Slightly incomplete for a 3-parameter tool with no schema descriptions.

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 has 0% description coverage, so description must compensate. It adds meaning for the 'sql' parameter by specifying required table reference format. However, 'timeout' and 'max_rows' are left unexplained, relying on their names. Partial compensation.

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?

Description clearly states 'Execute one-off Wdata SQL and return rows.' It uses specific verb+resource (run SQL) and distinguishes from sibling tools like wdata_run_saved_query by mentioning 'one-off' ad-hoc execution and referencing wdata_list_tables for table references.

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

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

Provides clear context: when to use (one-off SQL), critical constraint (table naming via sql_ref), and dialect (Trino). Implicitly distinguishes from wdata_run_saved_query. Lacks an explicit 'when not to use' statement, but context is strong.

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 bears full burden. It discloses the multi-step process, error surfacing, system column addition, and 409 duplicate behavior. It lacks explicit destructive hint but implies mutation.

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

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

Three sentences, front-loaded with purpose, no fluff. Every sentence adds value.

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?

Covers main behaviors (upload, import, poll, error handling, duplicate filename), but lacks detail on timeout and what 'settled' means. Mostly complete for a complex tool.

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

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

Schema coverage is 0%, so description must compensate. It only implicitly describes 'file_path' via file types listed; 'table_id', 'delimiter', and 'timeout' are unexplained. This is insufficient for a 4-parameter tool.

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 starts with 'WRITE. Upload a local .csv/.tsv/.json (or .zip of one) into a Wdata table and import it', clearly stating the action and resource. It specifies file types and distinguishes from other tools like wdata_run_sql.

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 notes that this tool handles upload+import+poll in one call, contrasts with 'upload alone does NOT import', and mentions error handling and duplicate filename behavior. While it doesn't explicitly name alternatives, it provides clear context for when to use this tool.

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

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

With no annotations, the description carries full burden. It discloses method restrictions (GET always, WRITE condition), base URL mapping for surface, and JSON string format. Also notes to record unknown errors with kb_add. Lacks authentication but acceptable for escape hatch.

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?

Description is a single compact paragraph with front-loaded purpose and efficient details. Every sentence adds value without 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 complexity (multiple surfaces, method rules, JSON params), description covers purpose, usage, surfaces, method constraints, and error handling. With output schema present, return values need not be explained. Complete enough for agent use.

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

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

Schema coverage is 0%, so description must compensate. It explains surface with three base URLs, and body_json/params_json as JSON strings. For path and method, it provides only minimal context beyond schema, but overall adds meaningful semantics.

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

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

The description clearly states it is an 'escape hatch for any endpoint not wrapped by a dedicated tool' and lists examples (tags, pivot views, etc.), distinguishing it from sibling dedicated tools.

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?

Explicitly says when to use (endpoints lacking a dedicated tool) and when not to (dedicated tools exist for read-style POSTs). Also specifies that GET is always allowed and other methods require writes enabled.

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