Lookbk

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: the server does not execute anything, the agent must run the returned command in the user's terminal. It stops short of stating preconditions (does the slug need to exist?) or whether the returned command is stable across calls.

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

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

Two sentences with no filler, front-loading the returned artifact and then the operational constraint. Every clause carries information an agent needs.

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

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

The tool has no output schema, and the description compensates by describing the return value as a one-line terminal command. Combined with the 100%-covered input schema and rich annotations, an agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100% and both enums are fully documented in the schema, so the description's restatement of the agent list and the user/project distinction adds no meaning beyond it. Baseline 3 applies; nothing about defaulting or enum interplay is clarified further.

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+resource ('Get the one-line terminal command that installs a Lookbk skill') and scopes it by agent and by user/project target. It is clearly distinguishable from list/search/get_skill siblings, though it never explicitly names them for contrast.

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

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

Usage is implied rather than stated: the description says the server never runs the command and the agent does, which tells an agent this is a fetch-then-execute flow. It does not say when to prefer this over get_skill or what to do if the user has already installed the skill.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. What the description adds beyond that is the return-content outline, which is genuinely useful given there is no output schema, but it says nothing about unknown-slug behavior or error responses.

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 that front-loads the operation and then enumerates returned fields in a compact list. No filler, no restatement of the title, and every clause conveys distinct 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 one-parameter, read-only lookup, the description covers both the action and the shape of the result, which substitutes well for the absent output schema. The only meaningful omission is what happens when the slug does not resolve.

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

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

Schema description coverage is 100% and the slug property already carries an illustrative example ("kinetic-title-drop"), so the description need only match that baseline. It adds no further meaning about slug format, case sensitivity, or where slugs come from, 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?

"Read one Lookbk skill in full" gives a specific verb (read) and a scoped resource (a single skill), and the enumeration of returned content (definition, requirements, package contents, exclusions, example prompt, install command) makes the payload concrete. It implicitly separates itself from list_video_skills and search_skills by emphasizing "one ... in full," though it never names those siblings.

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 phrase "one skill in full" signals a single-item lookup rather than discovery, but there is no explicit statement of when to choose this over search_skills or get_install_command, nor any note that a slug must first be obtained from a listing/search tool.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real context: these are skills that each 'render an MP4 on the user's machine', telling the agent the listing itself is local and non-rendering and that results are video generators. It does not mention pagination or result ordering.

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

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

Two short sentences, front-loaded with the verb and resource, with the parenthetical and second sentence both doing useful work. Nothing is redundant or padded.

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

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

For a one-optional-parameter, read-only listing tool with no output schema, this is close to complete and does not need to describe return values. The one gap for chaining purposes is that it never hints at what identifying fields a listed skill exposes (needed to feed get_skill or get_install_command).

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

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

Schema description coverage is 100% and the single optional `free` flag is fully documented in the schema ('true for free skills only, false for Pro only'), so the schema carries the load. The description adds nothing about the free/Pro filter or the default behavior when the flag is omitted, 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?

"List every Lookbk video skill" gives a specific verb plus resource, and the parenthetical enumerates the concrete skill categories so an agent knows what a 'video skill' is. It implicitly contrasts with search_skills by saying 'every', but never names the sibling or states the enumeration-vs-search boundary 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 only implied: 'every' suggests a full unfiltered enumeration, which is the natural alternative to search_skills, but the description never says when to pick this over search_skills or get_skill. No prerequisites or exclusions are stated.

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

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

Annotations already establish this as a safe, idempotent, closed-world read. The description goes beyond them usefully by naming the return payload (slug, output type, free or Pro, page URL), which matters because there is no output schema. It does not discuss ranking, empty-result behavior, or how strictly query is matched.

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, no filler, purpose front-loaded and the return shape second. The example queries are the highest-value content and appear immediately.

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

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

For a 4-parameter search with overlapping siblings and no output schema, the description covers intent and return fields adequately. Missing is any routing cue against list_video_skills/get_skill or indication of what happens when nothing matches.

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 baseline is 3. The description earns a bump by giving representative query strings ("product launch video", "og image"), which clarify the phrase-level, plain-language nature of the query field better than the schema's "What the user wants to make, in plain words."

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 ("Find Lookbk agent skills") plus the domain of use ("something the user wants to make"), and concrete query examples anchor what a skill is. It stops short of naming the sibling it is not, so an agent must infer how it differs from list_video_skills or get_skill.

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 examples imply when to reach for this tool (the user describes a desired artifact), but there is no explicit when-to-use vs list_video_skills, nor when to follow up with get_skill or get_install_command. Usage is inferable but not stated.

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