Menivor

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

With only openWorldHint declared, the description usefully discloses the two operating modes (draft-only vs render variants for every angle) and the multiplicative render scope. It stops short of disclosing cost magnitude, whether projects are persistent, or how to track an async render, which the annotations do not cover.

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

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

Two tight sentences with the primary action front-loaded and the optional render behavior following. No filler, though it is short enough that the brevity borders on underspecification rather than polished 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?

No output schema exists, so the description should say more about what comes back and the follow-up workflow. It never mentions polling a job (get_job) or estimating credit usage (generation_quote), leaving meaningful gaps for a multi-parameter generation tool.

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

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

Schema description coverage is 100%, so every parameter is already documented (including credits for render and avatar_id's requirement for ugc_avatar). The description's "every angle in the chosen formats and aspects" adds a small cross-parameter semantic but no syntax or format detail beyond the schema, so 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 uses specific verbs ("Extract", "draft") tied to concrete resources (a product from a URL, ad angles as an Ad Studio project), so the core action is unmistakable. It does not, however, explicitly contrast itself with any sibling such as create_reel or generation_quote, leaving differentiation to inference.

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

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

Usage is implied by the URL-to-ads workflow and the render=true condition, but there is no explicit when-to-use statement, no prerequisite (e.g., obtaining a quote or credits first), and no named alternative tool. An agent must infer that this is the entry point for URL-based ad generation.

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

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

Annotations only declare openWorldHint/destructiveHint, so the description carries real weight here and delivers: credit cost per variant, reservation at start, and release on render failure — non-obvious billing behavior an agent should know before calling. It omits auth/permission requirements, which keeps it from a 5.

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 tight sentences, front-loaded with the action, then cost semantics, then the async handoff. Every sentence earns its place with no filler.

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

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

With no output schema, the description correctly supplies the return value (job_id) and the polling workflow. For a 9-parameter mutation with billing side effects it is largely complete, though it says nothing about failure/error surfaces beyond credit release.

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

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

Schema description coverage is 100%, so every parameter (aspect, script, subject, language, variants, avatar_id, voice_name, caption_style, screen_recording_key) is already documented in the schema. The description only reinforces the credit-per-variant cost implied by the 'variants' param, adding little beyond the structured fields — baseline 3.

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

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

Specific verb+resource: 'Start rendering a vertical short-form reel.' It also names the async follow-up tool (get_job), which distinguishes it from sibling list/schedule/quote tools. An agent knows immediately this kicks off a render job.

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?

Clear context for use (start a render) and explicit routing for the follow-up step ('poll it with get_job'). It does not mention the sibling generation_quote for estimating cost beforehand, nor state when not to call it, so it stops short of full alternative 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?

readOnlyHint=true already tells the agent this has no side effects, and "signed" adds the meaningful detail that the result is a verifiable artifact. However, it does not disclose whether the quote expires, whether it must be echoed back into a generation call, or what pricing it covers - gaps that matter for a quoting 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 sentence front-loads the core action and uses a colon to attach the parameter guidance without filler. Nothing is wasted and the most decision-relevant information comes first.

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 the description never indicates what the quote returns (price, signature, id, validity window) or how it is consumed downstream. Annotations cover the safety profile, but the return-value gap leaves the definition only minimally complete for a quoting 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 100%, so parameters are documented in the schema itself (including examples). The description still adds value by framing profile and stages as alternative input modes, a relationship the schema does not express, plus noting the budget cap is optional.

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 artifact ("get a signed price quote") plus the temporal scope ("before generating"), which cleanly separates it from siblings like create_reel and schedule_publish. An agent can identify this as the pre-flight cost-estimation step without opening the schema.

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

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

"before generating" gives clear when-to-use context, and the two input modes (profile vs. stage mapping) imply different situations. It stops short of naming a sibling or stating exclusions, so it is clear context without explicit alternatives.

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

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

With readOnlyHint=true already covering safety, the description adds genuine behavioral context: it discloses the returned fields (state, progress) and the conditional nature of the download URL, which only appears once the job finishes. This is the key behavior an agent needs to avoid misinterpreting an incomplete response, though polling cadence or terminal-state semantics are not addressed.

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 returned fields are ordered by when they become available, which is efficient and readable.

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 one-parameter, read-only tool with no output schema, the description adequately covers what comes back and under what condition. Minor gaps remain around job state values and behavior for an invalid or expired job id, but nothing essential to invoking it correctly is missing.

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

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

Schema coverage is 100% and the single job_id parameter is already documented as 'Job id returned by create_reel', so the schema carries the semantic load. The description adds no parameter-level detail beyond that, making the baseline 3 appropriate.

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

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

States a specific verb ('Read') and resource ('reel job'), and even names the data returned (state, progress, download URL), so an agent knows exactly what it retrieves. It does not explicitly contrast itself with siblings, but its scope is distinct enough from create_reel or get_performance to be unambiguous.

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

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

There is no explicit 'use when' statement, but the phrase 'once finished, its download URL' implies polling a job until completion, which is a usable usage signal. The schema's 'Job id returned by create_reel' reinforces the workflow, yet the description itself never routes the agent or states 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that: it discloses that data is 'logged' performance, which metrics are returned, and that the no-argument path returns recent reels rather than erroring — behavior the annotations do not convey.

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 sentence, front-loaded with the verb and resource, with the branching condition trailing. Every clause carries information; nothing is redundant.

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

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

With no output schema, the description compensates by naming the returned metrics, and it covers both invocation modes and the optional-parameter behavior. For a 2-param read tool this is sufficient to call correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the branch semantics of job_id (one reel vs. listing) rather than just labeling it 'Optional reel job id'. limit's listing behavior is already covered by the schema description.

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

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

The description gives a specific verb ('Read'), a precise resource ('logged performance'), and enumerates the returned metrics (views, likes, retention). It also states the two operating modes (single reel by job_id vs. most recent reels), which no sibling tool covers, so an agent can distinguish it immediately.

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 condition that selects each mode: pass job_id for one reel, omit it for your most recent logged reels. That is actionable context, though it names no alternative tool or exclusion (e.g., what to use for cross-reel aggregate performance).

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds genuinely useful context the annotations don't cover — that prices are integer micro-USD and quoted per image, per second of video, or per audio clip. It says nothing about pagination, result size, or whether modality filtering is applied, so it adds value but stops short of rich behavioral disclosure.

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

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

One dense sentence with zero filler; the resource and the return-value semantics are both front-loaded. Nothing could be cut without losing information.

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

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

For a single-optional-parameter, read-only listing tool with no output schema, the description covers the essentials: what is listed and the shape of the returned pricing data. Only the behavior when modality is omitted and any result-size limits are unstated.

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

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

Schema description coverage is 0% for the single modality parameter, so the description must compensate. It does name the three modality values (image, video, audio) matching the enum, clarifying that modality selects a model category, but it never states whether omitting it returns all models — a meaningful gap at 0% coverage.

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

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

States a specific verb (List) and resource (media generation models) plus the scope of modalities covered and the data returned (integer micro-USD prices with per-unit basis). An agent immediately knows this is a model/pricing catalog call and can distinguish it from siblings like generation_quote or create_reel.

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: the description's emphasis on prices and model modalities suggests it is the discovery step before generation or quoting, but it never states when to call it versus generation_quote or wallet_balance, and gives no exclusions or prerequisites.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. 'And their status' hints at the returned content, but nothing about ordering, pagination, or result scope is disclosed.

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, containing no redundant or filler text.

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 parameterless list endpoint with no output schema, the description covers the 'what' but omits return-shape details such as pagination, ordering, or how many items come back, which the agent has no other source for.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. Nothing in the description is needed to clarify inputs.

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

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

States a clear verb and resource: 'List your scheduled publishes and their status.' It is readily distinguishable from the sibling schedule_publish (which creates a scheduled post rather than listing existing ones), though it never names that sibling 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?

Usage is implied by the name and description (use this to check scheduled posts and their status), but there is no explicit when-to-use, when-not-to-use, or alternative routing guidance among the many siblings.

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

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

Annotations only declare openWorldHint=true, so the description must carry the rest. It usefully discloses the deferred, time-triggered nature of publishing and the target accounts, but says nothing about permissions, failure handling, whether the schedule can be modified or cancelled, or how the job is dispatched.

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 verb and resource first and no filler. Every clause (finished, connected accounts, future UTC time) contributes information.

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

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

For a scheduling mutation with no output schema and 4 parameters, the description covers the core action but omits the optional privacy parameter and any statement about what happens after scheduling succeeds or fails. Adequate but with noticeable 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 50%, and the description restates the platform set and the UTC-time requirement already present in the schema, adding little new syntax or format detail. It never explains job_id or the youtube_privacy_status parameter, leaving those gaps unaddressed.

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 (schedule), resource (a finished reel), and destination (TikTok/Instagram/YouTube Shorts) plus the trigger (future UTC time). This clearly separates it from create_reel (creates content) and list_scheduled (reads scheduled items).

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 'finished reel' implies the prerequisite that the job must already be complete, and 'connected accounts' hints at the setup requirement, but no explicit when-to-use guidance, exclusions, or pointer to list_scheduled for verifying/cancelling schedules is given.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the useful detail that both available and reserved balances are returned in USD, but says nothing about auth requirements, caching/freshness, 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?

One short sentence, front-loaded with the verb and resource, with the returned fields appended. No filler and nothing that could be trimmed.

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 input parameters and readOnlyHint covering safety, the main gap was return content, and the description names the two balance figures and their currency, compensating for the absent output schema. Only freshness/auth context is missing.

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

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

The tool takes zero parameters, so the schema carries nothing an agent must interpret; the baseline of 4 applies. The description's only parameter-adjacent detail, the USD currency, is a return-value note rather than input semantics.

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

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

States a specific verb ('Read') plus resource ('your Menivor wallet') and even the payload returned ('available and reserved balance in USD'). No sibling tool overlaps, so an agent can immediately tell this is the balance-lookup operation.

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

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

Usage is implied by the verb and resource: call it when you need wallet funds. However, the description names no conditions, prerequisites, or alternatives, and gives no hint about when not to use it (e.g., versus generation_quote for cost estimation).

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