Audience Resolver MCP by Nova (CIVAI)

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

With no annotations, the description carries the full burden; it does disclose the important non-destructive trait ('Does not remove the drive file') and implies creation of an asset row. It omits permissions requirements, what happens on repeated calls with the same drive_file_id (duplicate assets?), and what identifier the caller gets back.

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 the action and scope, followed by one short negative clause that prevents the most likely misreading (that the file is moved). No filler.

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

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

For a four-parameter creation tool with no output schema and no annotations, the description covers what it does, the source prerequisite, and the safety profile. The main remaining gap is what the call returns (an asset id the caller uses as linked_asset_id) and duplicate-handling behavior.

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

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

Schema description coverage is 100%, so all four parameters are already documented at the field level; baseline 3 applies. The description adds the conceptual link between the drive file and the resulting asset consumed as linked_asset_id, but adds no format or constraint detail beyond the schema.

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

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

States a specific verb (copy) and resource (image/video already in the project Files drive) with the destination (asset library) and the downstream purpose (linked as linked_asset_id). This clearly separates it from upload_project_drive_file (which puts a file into the drive) and generate_calendar_row_asset (which generates rather than 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?

It gives a clear precondition (the file must already be in the drive via upload_project_drive_file) and the intended follow-up (link to a calendar row as linked_asset_id), plus an explicit exclusion that the drive file is not removed. It stops short of naming alternatives such as generate_calendar_row_asset or upload_publisher_image and when to prefer them.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it. It doesn't say whether the asset survives cancellation, whether partial output is retained, what happens if no generation is running, or whether permissions are required — all critical for a mutating cancellation call.

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

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

A single front-loaded sentence with no filler and the operation up front. It is efficient but borders on under-specified rather than maximally 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 mutation tool with no annotations and no output schema, one sentence is insufficient. An agent still lacks the precondition for a valid call, the failure mode, and what state the asset is in afterward.

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

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

Schema coverage is 50%: notification_message carries a rich schema description covering format and constraints, while asset_id is undocumented but self-evident. The description adds nothing about either parameter, but the schema does most of the work, so the baseline 3 applies.

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

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

Specific verb ('cancel') plus specific resource ('in-progress generation for a project asset') — notably not the asset itself, which separates it from delete_project_asset. It never names the sibling it could be confused with, so the differentiation has to be inferred from the wording alone.

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

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

The phrase 'in-progress generation' implies a precondition (only meaningful while a job is running) but never states it as guidance, and gives no alternative for a finished or failed asset. No mention of delete_project_asset or cancel_publishing_history as the adjacent routes.

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 behavioral burden. It usefully discloses the status precondition and the failure outcome for published rows, but says nothing about side effects on the Nova-side scheduling, whether cancellation is reversible, or how partial failures behave.

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

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

Three short sentences with the core purpose front-loaded, which is good. The trailing 'Uses publisher_pid in the URL path (same as schedule)' sentence is internal implementation trivia that does not help an agent invoke the tool and risks confusion with a different parameter name.

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

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

There is no output schema and no annotations, so the description must stand alone for a mutation tool. It covers preconditions and the primary failure case, but omits what the caller receives on success, what happens to already-queued Nova posts, and whether a cancelled entry can be rescheduled.

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

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

Schema description coverage is only 50%: history_id is undocumented in the schema, and the description never explains its format or how to obtain it, instead mentioning 'publisher_pid in the URL path', which is an internal routing detail irrelevant to the caller's argument. The remaining sentence does not compensate for the coverage gap.

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

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

Opens with a specific verb+resource ('Cancel a scheduled or pending publish') and narrows scope with '(Nova + local history)', which separates it from cancel_project_asset and delete_* siblings. It never explicitly contrasts with unschedule_calendar_row, the closest sibling alternative, so sibling differentiation is incomplete.

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 genuine eligibility rules ('Only works when history status is pending, publishing, or scheduled; published rows return not cancellable'), which tells the agent when the call will succeed. However, it offers no guidance on when to choose cancel_publishing_history over unschedule_calendar_row or list_publishing_history, so the alternative-selection guidance 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 behavioral burden, yet it discloses almost nothing. It does not say whether the parent calendar must already exist, whether the row is immediately visible or silent, what the mandatory calendar_id implies, or what is returned (and there is no output schema to fill that gap). Only "draft" conveys any state 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 single sentence is front-loaded and contains no filler. However, for a 12-parameter mutation tool it is far too thin to earn its place as the only guidance, so brevity here reads as under-specification rather than economy.

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 12-parameter create operation with no annotations, no output schema, and sparse schema descriptions needs substantially more explanation than one sentence. Nothing tells the agent about required context, defaults, side effects, or return 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?

Twelve parameters with only 25% schema description coverage, and the description mentions no parameters at all. Fields like post_type, target_platform, target_account_id, scheduled_at, linked_asset_id, and hashtags are left entirely unexplained in both places, so the description fails to compensate for the coverage gap.

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

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

"Add a draft row to a content calendar" names a verb and a resource, and the word "draft" hints at the pre-scheduling state. But it never distinguishes this from update_calendar_row, schedule_calendar_row, or delete_calendar_row, so an agent must infer which one to pick from the name alone.

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

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

There is no statement of when to use this tool versus alternatives. Siblings such as update_calendar_row, schedule_calendar_row, and create_content_calendar are all adjacent operations, and the description offers no routing guidance between them.

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

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

With no annotations, the description carries the full behavioral burden, but it only says the calendar may be 'blank or configured.' It does not say whether the call is destructive, whether it returns the new calendar's ID, what 'publisher-bound' implies about required account setup, or what happens if defaults are omitted.

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 padding. Its brevity is efficient, though it is close to under-specification rather than tight editing.

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

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

For a 5-parameter mutation tool with nested objects and no annotations or output schema, the description is far too thin. An agent gets no picture of the resulting calendar, the required project context, or how defaults shape what gets created.

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 80%, so the baseline is 3. The phrase 'blank or configured' loosely ties to the `source` parameter, but the description adds nothing about `default_targets`, `default_post_times` interactivity, or the `notification_message` fail-path that the schema already documents.

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?

Names a specific verb (create) and resource (content calendar) and scopes it to a publisher-bound project. It separates itself from row-level siblings (create_calendar_row) and from project creation, though it does not distinguish itself from import_content_calendar_json or nova_generate_calendar, which also produce 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?

No statement of when to use this versus import_content_calendar_json (bulk load from JSON) or nova_generate_calendar (AI-generated). No prerequisites are given, such as needing a bound publisher/project context, even though the description alludes to one existing.

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 does add one genuinely useful fact — that research starts in the background — but says nothing about that job being asynchronous, how to poll it, what happens on failure, whether creation is idempotent, or what permissions are required.

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

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

One front-loaded sentence with no filler, which is structurally good. But the brevity here is under-specification rather than economy — the single sentence is the entire description for a 10-parameter, side-effecting 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 complex creation tool with 10 params, no annotations, no output schema, and a background job, one sentence is nowhere near sufficient. Missing: parameter meanings, whether research is opt-in, return value (project ID?), and how it relates to get_project_initialization_status.

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?

Ten parameters with only 10% schema description coverage, and the description explains none of them. Cryptic names like promo, days_back, min_query, max_query, report_only and export_pdf are given no meaning anywhere, so an agent must guess at their semantics and types of values expected.

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

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

A specific verb+resource ("Create a project") plus the non-obvious side effect of launching background audience research. It never distinguishes itself from siblings like generate_research or list_projects, so an agent can't tell from text alone whether create_project also does the research those tools appear to cover.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternatives. With siblings such as generate_research, get_research_status and get_project_initialization_status present, the agent is left to infer the ordering and whether the background research is optional or duplicated elsewhere.

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 safety burden, and it does disclose one genuinely useful behavioral trait: queued Nova posts survive the row removal. It omits whether the deletion is permanent/reversible, what happens to already-scheduled or published assets attached to the row, and whether special 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?

A single tight sentence with the core action front-loaded and the caveat placed in a parenthetical. Nothing is wasted and nothing needs reordering.

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 zero annotations, no output schema, and two of three parameters undocumented, the description is too thin: permanence, effects on attached assets, and error/edge conditions (e.g. deleting a scheduled row) are all unaddressed.

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

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

Schema coverage is only 33% — only notification_message is documented, and that documentation lives in the schema, not the description. The description says nothing about what calendar_id and row_id must reference or how to obtain them, so it fails to compensate for the coverage gap.

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

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

The description gives a specific verb ('Remove') and a bounded resource ('one post row from a content calendar'), which also implicitly distinguishes it from the plural sibling delete_calendar_rows. It does not name that sibling or the cancel_* alternatives explicitly, so an agent still has to infer the boundary.

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 parenthetical 'does not cancel Nova-queued posts' hints at when this tool is insufficient and points at the cancel_* family by implication. However, there is no explicit 'use X instead' routing versus delete_calendar_rows, cancel_publishing_history, or unschedule_calendar_row, so the usage guidance remains 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious trait: queued Nova posts are not cancelled by row removal. However, it says nothing about whether generated assets are also removed, whether the action is reversible, what permissions are needed, or how many rows can be deleted per call.

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

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

A single front-loaded sentence with zero filler, and the scoping caveat is tucked into a parenthetical rather than burying the main verb. It is arguably too terse for a multi-parameter mutation, but nothing in it is wasted.

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

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

For a destructive, three-parameter mutation with no annotations, no output schema, and low parameter coverage, the description does the minimum: it clarifies the Nova-queue side effect but omits return behavior, partial-failure semantics, cascading asset deletion, and permission requirements.

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

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

Schema description coverage is only 33% — calendar_id and row_ids have no schema descriptions, and the description only obliquely implies them ("multiple post rows", "content calendar"). Constraints such as whether all row_ids must belong to calendar_id, ordering, or maximum batch size are undocumented anywhere.

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

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

States a specific verb and resource ("Remove multiple post rows from a content calendar"), and the word "multiple" distinguishes it from the singular sibling delete_calendar_row and from delete_content_calendar. It stops short of naming those siblings explicitly, so an agent must infer the distinction from the name and pluralization.

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

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

There is no statement of when to call this rather than delete_calendar_row, delete_content_calendar, or unschedule_calendar_row. The parenthetical exclusion is a behavioral note, not usage guidance, so the agent is left to infer bulk-delete intent from the name alone.

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, and it discloses nothing. For a destructive delete it says nothing about whether rows/assets are cascaded, whether the action is reversible, what permissions are required, or what the confirmation behavior is.

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

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

It is short, but the brevity reflects under-specification rather than economy. The only content beyond the name is an API namespace prefix that does not help an agent decide or invoke.

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 output schema, the description leaves every consequential question unanswered: what exactly is removed, whether calendar rows survive, and whether recovery is possible. The schema is trivial, so the description had room to say more and said nothing.

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?

There is a single optional parameter with 100% schema description coverage, which documents notification_message fully. Baseline 3 applies; the description adds no meaning beyond the schema, but nothing is missing either.

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 is essentially a restatement of the tool name plus an API namespace label ("Audience Resolver publisher API"). It implies deletion of a content calendar, but offers no scope, no object identity, and no differentiation from siblings like delete_calendar_row, delete_calendar_rows, or cancel_publishing_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?

There is no guidance on when to use this tool versus the many adjacent delete/cancel siblings, no prerequisites, and no exclusions. The agent must infer everything from the name alone.

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 behavioral burden, yet it says nothing about irreversibility, whether scheduled rows or publishing history referencing the asset are affected, required permissions, or the error/response shape. The only behavior disclosed—the notification_message fallback—lives in the schema, not the description.

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

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

A single front-loaded sentence with zero filler. It is efficiently structured, though the brevity borders on under-specification for a destructive 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?

For a destructive tool with no annotations, no output schema, and a half-documented parameter set, the definition omits everything an agent needs before calling: irreversibility, prerequisites, id provenance, and side effects on related calendar rows or publishing history.

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

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

Schema coverage is 50%: notification_message is documented in the schema, but asset_id has no description anywhere. The description does nothing to explain where asset_id comes from or what form it takes, so it fails to compensate for the coverage gap.

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

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

States a specific verb+resource ("Delete a project asset") plus the scope ("from the library"), which separates it from get_project_asset, update_project_asset, and list_project_assets. It does not address how it differs from the sibling cancel_project_asset, leaving a real ambiguity for an agent choosing between the two.

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 delete versus cancel or unschedule an asset, no prerequisite that the asset be unpublished/unscheduled, and no note that asset_id must come from list_project_assets. The agent must infer all routing.

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

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

With no annotations, the description must carry the full behavioral load. It does disclose the output shape (format_version 1, rows, default_targets, calendar_bundle), which is real added value, but it omits whether the call is read-only, any size limits or pagination on large calendars, and whether default_targets are resolved or raw.

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 the output format and the payload keys front-loaded, followed by the practical purpose. Zero filler and no repetition of the tool name.

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?

No output schema exists, so the description must cover return values — it does so at a useful level (format_version, rows, default_targets, calendar_bundle). Missing only safety/read-only disclosure and large-export behavior, which are modest gaps for an export utility.

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%, so calendar_id and publisher_pid are already documented. The description adds nothing on parameters beyond naming payload fields, and the third parameter (notification_message) is not addressed at all in the description, so the baseline 3 holds.

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

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

States a specific verb and resource ('Pull a content calendar as portable JSON') plus the payload contents (rows, default_targets), which distinguishes it from the read-only get_content_calendar. It never names the obvious counterpart import_content_calendar_json, so sibling differentiation is only implied.

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?

'Save calendar_bundle for git or edit offline' implies the use case (backup/versioning/offline editing), but there is no explicit when-not or direction to the import counterpart for round-tripping. An agent must infer that export pairs with import rather than being told.

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 zero annotations, the description carries the full behavioral burden, yet it says nothing about whether generation is synchronous or async, expected latency, cost/quota, or what happens when attach is true. Only the attach-optionality hint is added, which is thin for a generation tool that mutates calendar state.

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

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

A single short sentence with no waste, but that brevity comes at the cost of under-specification rather than economy. The key information (asset type, attach) is front-loaded, which is the one structural strength.

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 an 8-parameter generative tool with no annotations and no output schema, the description is far too thin. An agent cannot tell what context_file_ids or asset_instructions affect, nor how start_media_generation changes the flow, from this definition.

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

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

Schema description coverage is only 13% across 8 parameters, so the description must compensate and does not. It implicitly covers asset_type (image/video) and attach, but leaves calendar_id, row_id, context_file_ids, asset_instructions, notification_message, and start_media_generation 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 states a specific verb+resource: generating an image or video asset for a calendar row, with the optional attach behavior. It does not distinguish this from the sibling 'regenerate_calendar_row_asset', leaving a real ambiguity about which to pick.

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

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

No guidance on when to use this versus 'regenerate_calendar_row_asset', 'asset_from_drive', or 'get_row_generate_asset_context'. No prerequisites (e.g., whether the row must already exist or be in a particular state) 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It doesn't say whether generation is asynchronous (implied by the existence of get_research_status), whether an existing report is replaced or appended when 'extending', whether it consumes credits, or what triggers its failure mode.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the efficiency comes at the cost of under-specification rather than by compressing real 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?

A five-parameter mutation-style job starter with no annotations, no output schema, and 20% schema coverage demands far more than one sentence. Nothing about async behavior, return value, side effects, or the four undocumented parameters is covered.

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

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

Schema description coverage is only 20%: notification_message is documented, but publisher_pid, report_only, included_sections, and require_product_name_in_queries are bare. The description adds no meaning for any of them — notably it doesn't explain what 'report_only' toggles or what sections may be requested, so an agent must guess at four of five 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?

States a specific verb pair and resource: "Start or extend research for a project." An agent knows this creates or continues a research job on a project, but the description never contrasts with siblings like get_research_status or list_research_reports, so the agent must infer that those are read-only counterparts.

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?

"Start or extend" hints at when the tool applies but gives no explicit conditions, no prerequisites, and no named alternatives. Nothing tells the agent when to call this versus polling get_research_status or reading list_research_reports, nor when not to call it (e.g., research already complete).

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 behavioral traits are disclosed in the description, and no annotations are provided to offer context about read/write nature 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?

While short, the description is wholly uninformative and serves only as a label, offering no structural value to the agent beyond the function name itself.

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

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

The description is critically incomplete; it functions only as a name and fails to describe what the tool does, what data it accesses, or how it relates to the broader publishing API.

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%, giving the parameter semantics a baseline minimum score. The description does not add meaningful semantic context regarding the role of the notification_message parameter in the workflow.

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 merely repeats the API and function name ('Audience Resolver publisher API: get_content_calendar'). It does not state what specific content calendar information the tool retrieves.

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 provided on when to use this tool versus related sibling tools like 'list_content_calendars' or 'delete_content_calendar'.

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

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

With no annotations, the description carries the full burden and it discloses almost nothing: no mention of required permissions, behavior when the id is unknown, or what the returned asset contains. The one word 'Get' weakly implies a read-only operation but that is never confirmed.

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?

One short sentence, front-loaded with verb and resource, with zero filler. It is efficient but borders on under-specification rather than dense 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?

A two-parameter tool with no annotations and no output schema needs the description to explain the return value, the purpose of notification_message, and failure behavior; none of that is present. What remains is a bare restatement of the signature.

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

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

Schema coverage is 50%: notification_message is documented but asset_id has no schema description, and the description adds nothing about its format or where ids come from. Oddly, the description never explains why a read operation takes a notification_message, which is the most confusing parameter here.

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

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

States a specific verb and resource ("Get one project asset") plus the lookup key ("by id"), which is clearly distinguishable from list_project_assets or delete_project_asset. It stops short of naming any sibling, so an agent must infer that list_* is the plural alternative.

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

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

There is no statement of when to use this versus list_project_assets, get_row_generate_asset_context, or the update/delete asset siblings. The only guidance is the implicit 'you need exactly one asset', with no 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 behavioral burden, yet it only says 'poll'. It does not disclose whether this is read-only, whether repeated calls are expected/rate-limited, what state values can come back, or why notification_message would be used on a status check.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity borders on under-specification rather than optimal concision.

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

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

With no annotations and no output schema, the description is the only source of behavioral information, and it omits the polling lifecycle (expected states, retry cadence, completion signal) and the purpose of notification_message. For a polling-status tool this leaves real gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds nothing about publisher_pid or the odd notification_message parameter on a read-style polling tool, so the baseline 3 applies.

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

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

"Poll project initialization and research progress" gives a specific verb (poll) and a clear resource (project initialization + research progress). It is understandable on its own, but it does not differentiate itself from the sibling get_research_status, which sounds like it covers overlapping ground.

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 instead of get_research_status, no polling cadence, and no termination condition (i.e., which status value means 'stop polling'). The agent must infer all of this from the name.

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

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

No annotations exist, so the description carries the full burden, yet read-only behavior is only implied by "Get" and never confirmed. Nothing is said about error behavior for a missing/invalid id or what the returned record contains.

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

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

A single front-loaded sentence with no filler — the identifying information comes first. Its brevity is clean, though it leaves too much unsaid, which is penalized under other dimensions.

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

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

With no annotations, no output schema, and half the parameters undocumented, the description is too thin for a tool carrying a non-obvious notification_message parameter. An agent calling it correctly would need information this definition does not supply.

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 50%: notification_message is documented in the schema but the description never explains why a GET tool accepts a user-facing notification message or what the follow-up reply refers to. history_id is undocumented in both the schema and 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?

States a specific verb and resource ("Get one publishing history record") plus the lookup key ("by id"), which implicitly separates it from the sibling list_publishing_history. It stops short of naming that sibling explicitly for differentiation.

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 versus list_publishing_history or cancel_publishing_history, and no prerequisites stated. The agent must infer routing purely from the singular noun.

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 supplied, so the description carries the entire burden, yet it discloses nothing about whether calls are read-only, whether the job must be started elsewhere first, what status values exist, or whether polling is required. For a status tool whose whole value is interpreting job state, that is a large 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?

A single front-loaded sentence with no filler; it is terse rather than padded. It is under-specified, but that is a completeness problem, not a verbosity one.

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

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

With no annotations, no output schema, and an undocumented required parameter, the description should explain what the returned status means and how to proceed after it resolves. None of that is present, so an agent cannot confidently chain this into a workflow.

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

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

Schema coverage is 50%: notification_message is documented in the schema, but the required publisher_pid has no description anywhere. The description says 'for a project' while the parameter is named publisher_pid, leaving the identifier's meaning ambiguous instead of clarifying it.

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 names a specific verb and resource ('Get research job status') plus a scope ('for a project'), so an agent can tell this is a status-read tool rather than the job-creation tool. It stops short of naming the sibling that starts the job (generate_research) or the one that lists finished output (list_research_reports).

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

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

There is no statement of when to call this versus generate_research, get_project_initialization_status, or list_research_reports, and no note about polling/repeat invocation. Usage is only inferable from the word 'status'.

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

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

No annotations are provided, so the description carries the full burden and largely drops it. It never confirms this is a non-mutating read, never says what fields the 'context' contains, and never mentions permissions or failure behavior. The word 'generate' in the name/description actively blurs whether the call produces an asset or merely describes one.

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

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

It is a single front-loaded sentence with no padding, which is structurally clean. However, brevity here comes at the cost of substance — the sentence is short because it omits necessary information, not because it is 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?

With no annotations, no output schema, and three parameters, the description is the only source of behavioral and return-value information, and it supplies almost none. An agent cannot tell what the returned 'context' looks like or how to use it, which is the entire point of a context-fetching 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 only 33%, and the description adds no parameter meaning whatsoever. Only notification_message is documented in the schema; calendar_id and row_id are bare strings with no explanation in either place, and the description does not clarify whether row_id is scoped to calendar_id or how the notification message is surfaced to the user.

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?

It states the resource (a calendar row) and what the payload is for (AI image/video generation context), which is more than a restatement of the name. But 'Row context' is a noun phrase rather than a verb+resource, so an agent must infer this is a retrieval tool from the 'get_' prefix alone. It also does nothing to distinguish itself from generate_calendar_row_asset or regenerate_calendar_row_asset, which sound closely related.

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

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

There is no when-to-use guidance, no prerequisite, and no named alternative. An agent could reasonably guess this is a pre-generation lookup, but that is inference rather than instruction. Nothing tells it whether to call this before generate_calendar_row_asset, or whether it is ever needed standalone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that replace clears rows on replace_calendar_id while keeping the same id, and that Twitter usernames are resolved to account_id, but it omits permissions, reversibility, failure behavior, and return 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 two tight sentences with the action and mode semantics front-loaded. The username-resolution note is additional but relevant, and there is no filler.

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

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

For a mutation/import tool with no annotations and no output schema, the description covers the key destructive replace behavior and username resolution. It still leaves gaps around permissions, failure handling, and what the caller should expect after import.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the enum values for calendar_import_mode and the conditional requirement for replace_calendar_id. The description reinforces mode semantics and mentions username resolution, but does not add substantial parameter-level information 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 states a specific action and resource: pushing portable calendar JSON, with modes for creating a new calendar or replacing rows in an existing one. It clearly distinguishes the two import modes, though it does not explicitly differentiate this tool from nearby siblings such as import_webpage_calendar or create_content_calendar.

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 implied guidance through the create/replace mode distinction and the warning that replace clears rows on replace_calendar_id. However, it does not say when to choose this tool over alternatives like import_webpage_calendar, create_content_calendar, or export_content_calendar_json.

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

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

With no annotations, the description carries the full burden. It does disclose a real prerequisite ('Requires Nova API key in AR Settings') and the extraction pipeline, which is genuine added context. It omits whether a new calendar or row is created, whether the operation is asynchronous (siblings like get_research_status suggest polling patterns), and what happens on failure.

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

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

Two short sentences, front-loaded with the action and target, followed by the prerequisite. No filler, no restatement of the name.

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 4-parameter mutation-style tool with no annotations, no output schema, and 25% schema coverage, the description is thin. It leaves unclear what 'calendar draft' means concretely, whether an asset/row is created, how import_notes and import_title are used, and whether the call is async.

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 only 25%: only notification_message is documented in the schema. The description adds one useful constraint on import_url ('public webpage'), but says nothing about import_notes or import_title, so two of four parameters remain fully 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?

States a specific verb (import) and resource (a public webpage into a calendar draft), plus the mechanism (Nova extract + LLM). This distinguishes it from siblings such as import_content_calendar_json or create_calendar_row. It stops short of naming which calendar the draft lands in, leaving some ambiguity.

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

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

Usage is only implied: you have a public URL and want it turned into a calendar draft. There is no explicit when-to-use vs. when-not guidance and no routing to alternatives like import_content_calendar_json or create_calendar_row, even though both appear in the sibling set.

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

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

With no annotations, the description carries the full behavioral burden and delivers essentially nothing: no indication of whether this is a read-only list, whether results are paginated or scoped to a workspace/account, or what authorization is needed. The only added context is the API namespace ('Audience Resolver publisher API'), which implies an external service but reveals no behavior.

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

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

It is short, but the brevity is under-specification rather than efficiency: a single fragment that spends half its words on a namespace label and none on the actual operation. Nothing is front-loaded because nothing informative is present.

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

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

There is no output schema and no annotations, so the description is the only source of context — and it provides none about return shape, scope, or filtering. Given a dense 40-tool sibling set where the agent must pick between list/get/create/delete calendar variants, this is far below what is needed.

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?

There is a single optional parameter (notification_message) and schema description coverage is 100%, so the schema already explains it fully; per the high-coverage baseline the score is 3. The description adds no additional parameter meaning, but none is needed.

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

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

The description is effectively a tautology: it prefixes the tool name with a namespace ('Audience Resolver publisher API') and restates 'list_content_calendars' without explaining what listing a content calendar returns or how it differs from siblings like get_content_calendar or list_projects. An agent must infer everything from the name alone.

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

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

There is no guidance on when to use this versus get_content_calendar, create_content_calendar, or the other ~39 calendar/project tools. No prerequisites, no when-not-to-use, no alternatives are named.

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 behavioral burden and does not meet it. It never confirms read-only semantics, does not describe pagination, result volume, ordering, permissions, or the failure-path behavior implied by the notification_message parameter.

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

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

A single short sentence, front-loaded with the action and resource. The parenthetical filter note is mildly redundant with the schema but costs little.

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

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

With no annotations, no output schema, and no sibling differentiation, the description should do more. An agent still cannot tell what scope of assets is returned, whether results are paged, or why a listing tool takes a notification_message fallback parameter.

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

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

Schema description coverage is 100%, so the schema already explains both parameters, and the baseline is 3. The description echoes the asset_type filter without adding syntax or accepted values, and says nothing about notification_message.

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

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

The description states a specific verb and resource ("List project media assets in the library"), which is more than a tautology. However, it never clarifies which project is being listed (there is no project identifier parameter, yet the effect is project-scoped) and gives no differentiation from adjacent siblings such as get_project_asset or list_project_drive.

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 only guidance is "optional asset_type filter," which merely restates the schema. There is no statement of when to use this versus get_project_asset (single asset) or list_project_drive (drive files), and no 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, the description carries the burden itself: "List" implies a safe read and it usefully discloses the returned media types. However, it says nothing about pagination, ordering, result limits, or whether an empty drive is possible, and does not address the unexpected notification_message parameter on 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?

A single dense sentence that front-loads the resource and then qualifies the contents; no filler. It is terse to the point of omitting required-call information, but the sentence itself 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?

The description adequately covers what is returned, which is the main thing an agent needs from a list tool with no output schema. It is incomplete on the required publisher_pid and the semantics of notification_message, so the agent cannot call it confidently from the description alone.

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

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

Schema coverage is only 50%, and the undocumented parameter is the required publisher_pid, which the description never mentions or explains. The one documented parameter, notification_message, is also unexplained in the description and is counterintuitive for a list operation.

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

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

States a specific verb+resource ("List the project Files tab drive") and enumerates the exact content it returns (research .md reports plus uploaded images, video, pdf, md, txt). This makes the scope distinguishable from list_project_assets and list_research_reports, though those siblings are never named explicitly.

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

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

There is no when-to-use / when-not-to-use guidance and no mention of alternatives, despite several overlapping siblings (list_project_assets, list_research_reports, get_project_asset). The only hint is the scope phrase "project Files tab drive", which leaves the agent to infer routing on its own.

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

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

With no annotations, the description carries the full behavioral burden and delivers almost nothing: no statement that it is read-only, no pagination or result-count behavior, no return shape, no ordering. 'List' weakly implies a safe read, but nothing is confirmed.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though efficiency here shades into under-specification rather than deliberate brevity.

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

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

For a tool with no annotations and no output schema, one sentence is far too thin — the agent learns nothing about what a 'project' record contains, whether results are paginated, or how the publisher-key scope affects results. Key decision inputs are missing.

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

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

Schema description coverage is 100% and there is only one optional parameter, so the baseline is 3 under the rubric. The description adds nothing about notification_message, which is an unusual parameter for a read operation and whose purpose (a follow-up failure message) is only explained in the schema.

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

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

States a specific verb ('List') and resource ('Audience Resolver projects') plus an access scope ('with the publisher key'), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from siblings like list_project_assets or list_project_drive, which sit in the same naming family.

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

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

There is no statement of when to use this versus the many other list_* tools, no mention of preconditions, and no exclusions. The publisher-key phrase is an access constraint, not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the side effect of syncing pending items from Nova and the publisher_pid path requirement, but it does not state whether the operation is read-only overall, what happens to existing history, or any auth/rate-limit details.

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 core action and immediately followed by the important sync side effect and prerequisite. There is no wasted text, though 'same as schedule_calendar_row' is slightly cryptic without that tool's context.

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 list tool with one optional parameter and no output schema, the description covers the action, side effect, and path prerequisite. However, it lacks detail about return shape/pagination and does not clarify its relationship to get_publishing_history_item, leaving some contextual gaps.

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

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

Schema coverage is 100%, so the schema already documents the single optional notification_message parameter. The description adds useful context about a publisher_pid path parameter not present in the input schema, but it does not explain notification_message semantics beyond what the schema provides.

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

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

The description states a specific verb and resource ('List publishing history') and scopes it to the project. It also discloses a notable behavior ('syncs pending items from Nova') that distinguishes it from a pure read. It does not explicitly distinguish itself from the sibling get_publishing_history_item, but the purpose is clear.

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

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

Usage is implied by the tool name and the mention of syncing pending items, but there is no explicit guidance on when to use this versus get_publishing_history_item or cancel_publishing_history. It does provide the prerequisite that publisher_pid is required in the URL path, which is useful 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 exist, so the description bears the full burden. It implies a read operation but says nothing about pagination, ordering, result limits, permissions needed, or what an empty result means — all relevant for a listing tool with an undocumented required identifier.

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?

One short sentence with no filler, so nothing is wasted. But the terseness reflects under-specification rather than disciplined conciseness — there is no front-loaded scope detail beyond "for a project."

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 two-parameter tool with no annotations, no output schema, and an undocumented required parameter, the description should carry much more context. As written, an agent cannot confidently determine required input format or what the listing returns.

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 only 50%: notification_message is documented in the schema, but the required publisher_pid has no description anywhere and the tool description does not explain it (project id? publisher id? format?). With the single required parameter left ambiguous, the description fails to compensate for the coverage gap.

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

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

The description names a verb ("List") and a resource ("research report files") scoped "for a project," so the basic operation is discernible. However, it gives no signal for distinguishing this from close siblings like list_project_assets or get_research_status, leaving the agent to infer the boundary.

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

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

There is no statement of when to use this tool versus the many neighboring list_* tools (list_project_assets, list_project_drive, list_projects) or research-related tools. No prerequisites or exclusions are given; usage is entirely inferred from the name.

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

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

No annotations are provided, so the description carries the full burden and it only adds 'Nova-linked' as context. It does not state that this is a read-only/non-mutating operation, what auth or scope is needed, whether results are paginated, or why a list operation would take a notification_message parameter.

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

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

A single well-formed sentence with no filler, front-loading the verb and resource. It is sized appropriately, though it spends most of its words on the platform list that the schema already supplies.

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 two-parameter read tool with no annotations and no output schema, the description is minimally viable but leaves the notification_message behavior and the overlap with list_twitter_accounts unresolved. Nothing catastrophically missing, but an agent could call it correctly yet misinterpret the reply-failure semantics.

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

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

Schema description coverage is 100%, so the baseline of 3 applies; the description's enumeration of platform keys merely restates the schema's own examples. The notification_message parameter — unusual for a read operation and relevant to follow-up reply behavior — is entirely unexplained 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?

States a specific verb and resource ('List Nova-linked social accounts') and scopes it to a single platform, with the valid platform keys enumerated. It does not, however, distinguish itself from the sibling list_twitter_accounts, which overlaps at least partially in 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 sentence conveys what the tool returns but gives no when-to-use framing, no prerequisites, and no guidance on alternatives — notably list_twitter_accounts appears in the sibling list and is never mentioned or excluded. An agent must infer routing on its own.

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 disclosure burden, yet it says nothing about pagination, result size, auth requirements, or failure behavior. The only signal is the reference to an external "Audience Resolver publisher API," which hints at a remote dependency but conveys no operational 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?

It is one line with zero waste, but it is under-specified rather than concise — the namespace prefix is front-loaded while the actual purpose, scope, and return shape are absent.

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

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

With no annotations and no output schema, the description needed to explain what is listed and what comes back, and it does neither. The lone parameter being notification_message makes the tool's behavior even less self-evident to 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?

Schema description coverage is 100%, so notification_message is already fully documented in the schema, which sets the baseline at 3. The description adds nothing about that parameter, and notably does not explain why a listing tool takes a notification message 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 is essentially the tool name restated after a namespace prefix: "Audience Resolver publisher API: list_twitter_accounts." The verb "list" and resource "twitter_accounts" come from the name itself, not from explanatory prose, and nothing distinguishes it from the sibling list_social_accounts.

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 indication of when to call this versus list_social_accounts or the other list_* siblings, no prerequisites, and no exclusions. The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full burden. It does disclose three useful traits: the return format (rows markdown), the fact that nothing is persisted, and the auth dependency (Nova API key in AR Settings). It says nothing about latency/cost of a model-backed generation, failure modes, or whether output is deterministic, which matter for a generative tool.

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

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

Two compact sentences with zero filler; the core action comes first and the workflow/auth caveats follow in the parenthetical. Nothing is repeated from the schema.

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

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

There is no output schema, but the description partly compensates by stating the return is markdown rows. However, for a 5-parameter generative tool with no annotations, leaving the three required parameters undefined means an agent cannot confidently construct a correct call from this definition alone.

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

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

Schema coverage is 40%: generate_channels and notification_message are documented in the schema, but the three required parameters — generate_title, generate_scope, generate_brief — have no descriptions anywhere and are not mentioned in the tool description. The most important inputs (especially what 'scope' means and what format 'brief' expects) are left entirely to inference.

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

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

States a specific verb and resource ("Draft a content calendar with Nova") and explicitly separates itself from the persistence siblings create_content_calendar and create_calendar_row. An agent can tell this is the generative/drafting step, not the storage step, without opening any schema.

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

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

The parenthetical makes the workflow explicit: this tool drafts, then you persist via create_content_calendar + create_calendar_row. It also names a prerequisite (Nova API key in AR Settings). It stops short of stating when NOT to use it (e.g. when a calendar already exists and you should use update_content_calendar or import_webpage_calendar).

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

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

With no annotations, the description carries the full burden. It does disclose useful behavior: per-target caption fallback, post-type defaulting to reel, and the ignore-priority of single-target fields. It says nothing about what publishing does irreversibly, permission/auth requirements, partial-failure behavior when fanning out to many accounts, or rate limits — significant gaps for a high-stakes write 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?

Three sentences, zero filler, front-loaded with the primary action followed by the two calling shapes and the scheduling flag. Each sentence 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 9-parameter mutation tool with no annotations and no output schema, the description covers parameter interplay well but omits the return value (per-target success/failure or post ids) and error behavior. An agent would still be guessing about what comes back after a multi-account publish.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the publish_targets sub-fields and their captions. The description mostly restates the same mutual-exclusion and defaulting rules rather than adding syntax, format, or constraint details the schema lacks. Baseline 3 applies.

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

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

The description opens with a specific verb+resource+scope: 'Publish or schedule an asset to one or many connected social accounts.' That is far more informative than the name alone. It does not explicitly contrast with near-neighbor siblings such as schedule_calendar_row or schedule_all_calendar_rows, so an agent must infer the asset-vs-calendar-row boundary.

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 clearly states the two invocation modes — multi-account via publish_targets, single via publish_platform + publish_account_id — and that an empty publish_scheduled_at means publish now. That is genuine when-to-use guidance. It gives no exclusion rules against sibling scheduling tools, which keeps it below 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?

No annotations are provided, so the description carries the full burden and does not meet it. It doesn't say whether the existing asset is replaced or a new version is added, whether the call is synchronous or long-running, or what attach/start_media_generation do — all critical for a mutation that overwrites generated output.

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

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

It's a single front-loaded sentence with no filler, so nothing is wasted. But brevity here comes at the cost of substance — the parenthetical reads like an internal note rather than agent-facing guidance.

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

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

Eight parameters, one of them an enum, no annotations, and no output schema — this is a complex mutation tool whose description covers none of the operational detail an agent needs. It doesn't even say what comes back (asset ID, status) or how regeneration interacts with scheduling/publishing.

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

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

Schema description coverage is only 13% (just notification_message), and the description adds nothing about the other seven parameters. Undocumented booleans like attach and start_media_generation and the context_file_ids array are left entirely ambiguous, and 'required instructions' doesn't clarify asset_instructions' format or expected length.

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 names a specific verb and resource ('Regenerate row asset') and distinguishes itself from the sibling generate_calendar_row_asset by noting that new instructions are supplied. It's clear enough to pick out of a long sibling list, though 'row asset' remains domain jargon without further grounding.

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 parenthetical 'same as generate with required instructions' implies this is the variant to use when re-running generation on an existing row asset, but it never states when to choose regenerate over delete-then-generate, or what preconditions (existing asset, row state) must hold. Usage is implied rather than prescribed.

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 behavioral burden and discloses nothing. It does not say whether this is a mutation, what happens to rows already scheduled, whether it requires publishing permissions, whether it is reversible, or what the result contains. For a bulk scheduling operation this is a serious 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?

It is short, but the brevity comes from under-specification rather than efficiency. The one sentence is a label, not a front-loaded purpose statement, and it contains no information an agent could act on.

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

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

With no annotations, no output schema, and a bulk mutation whose scope and side effects are undefined, the description leaves everything an agent needs unanswered. It is inadequate for a tool that likely modifies many calendar rows at once.

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

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

Schema description coverage is 100%, so the single notification_message parameter is fully documented in the schema itself, which sets the baseline at 3. The description adds nothing about the parameter, but the schema does the work.

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

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

The description is a restatement of the tool name prefixed by an API label ('Audience Resolver publisher API'), not an explanation of what scheduling all calendar rows means. It never states the resource scope (all rows in a calendar? all calendars?) or a verb-plus-object description beyond the identifier. An agent cannot distinguish it from the sibling schedule_calendar_row from this text.

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

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

No when-to-use, when-not-to-use, or prerequisite information is given. The sibling list contains schedule_calendar_row and unschedule_calendar_row, which are obvious alternatives for the same resource, yet the description offers no criteria for choosing bulk vs. single-row scheduling.

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

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

With no annotations, the description carries the full burden, and it does disclose a non-obvious behavior: the tool inspects Post Type and media URL to choose a platform-specific format (YouTube short vs video, LinkedIn video vs feed, Instagram reel). It says nothing about whether this publishes immediately or queues, what happens if Post Type is unset, or whether the operation is reversible.

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, with zero filler. The second sentence is telegraphic and slightly hard to parse, but it is dense rather than 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?

For a scheduling mutation with no annotations and no output schema, the definition covers the format-selection logic but omits the essentials an agent would want: where the schedule date/time comes from (there is no such parameter), failure modes, and whether social accounts must already be linked.

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 single parameter has 100% schema description coverage, so the baseline of 3 applies. The description never mentions notification_message or its fallback-reply role, adding no 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?

States a specific verb and resource ("Schedule one calendar row on Nova"), and the word "one" implicitly separates it from schedule_all_calendar_rows. It doesn't name that sibling or unschedule_calendar_row explicitly, so differentiation is inferred rather than stated.

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

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

The mention that Post Type is "set via update_calendar_row" implies a prerequisite step and points at the right sibling to run first. However, there is no explicit when-to-use/when-not guidance, no reference to schedule_all_calendar_rows for bulk work, and no stated preconditions such as a connected social account.

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

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

With no annotations, the description carries the full burden and does disclose the mutation's side effects: cancelling linked publishing history 'when still cancellable' (conditional behavior made explicit) and clearing publishing_history_id and scheduled_at. Not covered: required permissions, idempotency/repeat-call behavior, or what occurs when the history is already published and no longer cancellable.

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 dense sentences: the action and its side effects come first, the alternative-preference note last. No filler, and the field-clearing detail is parenthetically 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?

For a mutation tool with no annotations and no output schema, the description explains what changes and under what condition, which is the essential information. Remaining gaps — auth requirements and behavior for rows that cannot be unscheduled — are real but secondary.

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

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

Schema description coverage is 100% for the single optional notification_message parameter, so the schema already documents it fully. The description adds nothing about the parameter, which is acceptable at full coverage but leaves the baseline.

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

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

States a specific verb ('Unschedule') and resource ('one calendar row') and immediately enumerates the mechanics: cancelling linked publishing history and resetting the row to draft. It contrasts with patching scheduled_at alone, but never names the closely-related siblings (delete_calendar_row, cancel_publishing_history, update_calendar_row), so an agent must still infer the boundary.

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 clause 'Prefer this over PATCH scheduled_at alone' gives an explicit preference and implied alternative path. It does not cover exclusions — when to call cancel_publishing_history or delete_calendar_row instead, or what happens if the row was never scheduled.

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. 'Patch' implies mutation and the parenthetical discloses partial-update behavior, but it says nothing about permissions, side effects, reversibility, required identifiers, or what happens to omitted fields.

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

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

The description is a single front-loaded sentence with no wasted words, and the parenthetical adds the most important usage nuance. It is arguably too terse for a 13-parameter mutation, but it is not structurally bloated.

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 13-parameter mutation with no annotations, no output schema, and only 15% schema description coverage, one sentence is not enough. It establishes patch semantics but leaves field meanings, required ID roles, side effects, and response behavior unexplained.

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

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

There are 13 parameters with only 15% schema description coverage, and the description does not explain the undocumented fields such as cta, day, caption, hashtags, scheduled_at, linked_asset_id, target_platform, or target_account_id. The note about passing only intended changes is directionally useful but does not compensate for the coverage gap.

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

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

The description uses a specific verb, 'Patch', and names the resource, 'one calendar row', so the basic operation is clear. It does not explicitly distinguish this from siblings such as create_calendar_row, delete_calendar_row, or schedule_calendar_row, which prevents a top score.

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 parenthetical 'only pass fields you intend to change' is useful guidance for partial updates, but it does not explain when to use this tool instead of create_calendar_row, schedule_calendar_row, or delete_calendar_row. There are no explicit 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?

With no annotations provided, the description carries the full behavioral burden and does almost nothing: it does not say whether patching default_targets/default_post_times retroactively affects already-scheduled rows, whether partial patches leave unspecified fields untouched, or what permissions are required. The one documented parameter (notification_message) hints at a failure-notification flow that the description never explains.

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

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

A single short sentence is front-loaded and wastes no words, but its brevity here is under-specification rather than efficiency for a five-parameter mutation tool with nested objects.

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?

This is a mutation tool with nested-object parameters, no annotations, no output schema, and 20% schema coverage, yet the description supplies none of the missing context an agent would need to call it safely. The gap is large relative to the tool's complexity.

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

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

Schema description coverage is only 20%, and the description names just three of five parameters without explaining the patch_ prefix convention or the expected shape of the nested default_targets and default_post_times objects. calendar_id and the notification_message fallback behavior are left entirely to the schema, which documents neither meaningfully.

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 names a specific verb (patch) and enumerates the mutable fields (title, default_targets, default_post_times), so the operation is identifiable. However, it says only "calendar" and never disambiguates from the sibling update_calendar_row or ties itself to the content calendar resource implied by its name, leaving an agent to infer scope.

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

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

There is no statement of when to use this tool versus update_calendar_row, create_content_calendar, or import_content_calendar_json. No prerequisites, no note that this mutates calendar-level defaults rather than individual rows, and no 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 present, so the description carries the full burden and does little: it says 'update' but not whether this is a partial patch (only listed fields changed, others preserved), whether it requires ownership/permissions, what happens on an invalid asset_id, or whether the change is reversible. For a mutation tool with zero annotation coverage this is a substantial 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?

A single front-loaded sentence with no filler, which is appropriate in form. It is efficient but borders on underspecified rather than over-long, so it sits just below the top mark.

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

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

With no annotations, no output schema, low schema coverage, and five parameters, the definition should explain mutation semantics, field-omission behavior, and error/shape of the result. None of these are addressed, leaving the agent under-informed 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?

Schema description coverage is only 20%, and the description does helpfully name three of the five parameters (caption, prompt, guidelines), which partially compensates. However it says nothing about patch semantics for the patch_* parameters, does not clarify the required asset_id, and adds nothing about notification_message beyond what the schema already documents.

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

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

Specific verb (Update) plus resource (project asset) and an enumeration of the mutable fields (caption, prompt, guidelines). An agent can tell it apart from delete_project_asset or get_project_asset, though it doesn't explicitly contrast with the other update_* siblings such as update_calendar_row.

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 statement of when to use this tool versus alternatives (e.g. update_calendar_row, regenerate_calendar_row_asset), no prerequisites, and no indication that the asset must already exist. The agent must infer all routing decisions from the name alone.

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 does disclose that a drive file id is returned and hints at the downstream use (calendar generate context attachment), which is valuable, but it says nothing about required permissions, overwrite/naming collisions, or what happens to an existing file with the same 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?

Three short sentences, front-loaded with the action and location. The final sentence about the return value is grammatically rough ('for calendar generate context attachment') but still compact and information-bearing.

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

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

For a 5-param mutation tool with no annotations and no output schema, the description covers the action, size strategy, and return value, but leaves the required publisher_pid and upload failure/permission behavior unexplained. Adequate but 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 80%, so the schema already documents file_url, file_base64, upload_filename, and notification_message. The description only restates the file_url-for-large-files rule already present in the schema and adds nothing on publisher_pid, which is the sole required parameter but undocumented in both places.

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

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

States a specific verb and resource: upload a file into the project Files tab (context/). An agent can tell this is a project-scoped file upload, though the description never distinguishes it from siblings like asset_from_drive, upload_publisher_image, or upload_publisher_video.

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 line 'Use file_url (https) for large files' gives a clear param-selection rule for size, but there is no guidance on when to choose this tool over asset_from_drive or the publisher image/video uploaders, and no stated preconditions.

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 usefully discloses the return values (asset_id, media_url) and that media_url is intended for row linking, plus a size ceiling for base64. It does not state permission requirements, whether re-uploading overwrites an existing asset, or failure behavior — meaningful gaps for an unannotated 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?

Two sentences, front-loaded with the action and accepted formats, then the return contract. No filler and nothing duplicated from the schema.

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

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

No output schema exists, and the description compensates by naming exactly what comes back and how it is consumed (asset_id and media_url for row linking). Combined with a fully described five-parameter schema, an agent has enough to call this correctly; the missing pieces are project resolution and overwrite semantics, which are secondary.

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

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

Schema description coverage is 100%, so all five parameters are already documented with preference and size guidance. The description adds only the implicit mutual exclusivity of image_url vs image_base64 via 'or', which is baseline-level value when the schema does the heavy lifting.

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 names a specific verb (upload) and resource (PNG/JPEG image) bound to a publisher-scoped AR project, and the accepted formats distinguish it from the sibling upload_publisher_video. It stops short of naming competing siblings like asset_from_drive or upload_project_drive_file, so the differentiation is implicit rather than explicit.

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 parenthetical '(image_url or small image_base64)' hints at two input paths and the schema clarifies the size/preference tradeoff, but the description gives no guidance on when this tool is the right choice versus asset_from_drive or upload_project_drive_file. Usage is implied by the publisher-bound scope 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?

With no annotations, the description does carry useful behavioral detail: the file is fetched from a public URL (download-then-ingest), accepts mp4/webm/mov up to 200MB, and returns an asset_id used downstream as linked_asset_id. It does not say whether the video is copied into the project, how long ingestion takes, what happens on failure, or whether re-uploading overwrites an existing asset.

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 dense sentences with constraints and return value front-loaded, and zero filler. Every clause carries operational information (format, size, source mechanism, output handle).

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

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

For a 5-parameter ingestion tool with full schema coverage and no output schema, the description covers source, constraints, and the returned handle needed to chain into create_calendar_row/update_calendar_row. What's missing are error/retry semantics and any note on whether large uploads are asynchronous.

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%, so parameter definitions already do the heavy lifting and the baseline would be 3. The description goes beyond the schema by naming the return value (asset_id) and its relationship to another tool's parameter (linked_asset_id), which no property description states.

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

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

States a specific verb and resource: upload a video into the publisher-bound AR project's asset library, with format and size constraints inline. The media type (video) and destination (publisher AR asset library) distinguish it from siblings like upload_publisher_image, asset_from_drive, and upload_project_drive_file without needing to name 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?

Implicit usage is discernible: you have a public https video URL and want it in the AR asset library, and the returned asset_id is meant to feed linked_asset_id on a calendar row. However, there is no explicit 'use this instead of X when...' routing against asset_from_drive or upload_publisher_image, and no stated prerequisites beyond the URL itself.

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