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

With no annotations provided, the description carries the full burden. It explains that the crawler captures passively during manual posting on facebook.com and that resnapshot is only needed when Facebook rotates payloads. This gives valuable behavioral context beyond a simple status read.

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

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

The description is two sentences, front-loads key information (status of templates, readiness, actions), and contains no filler. Every 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?

Given no parameters and no output schema, the description adequately explains what the tool provides (templates captured, readiness, instructions). It could optionally mention return format or error states, but the description is sufficient for a simple status 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?

There are zero parameters, and schema coverage is 100%. The description adds meaning by explaining what the tool returns and the underlying mechanism, which is more than the empty schema provides. This is appropriate for a parameterless tool.

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

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

The description clearly states that the tool provides crawler/snapshot status, listing specific details like which templates are captured, readiness to post, and instructions for resnapshot. It distinguishes from sibling tools (which are action-oriented like post_photos or switch_profile) by focusing on status.

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

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

The description implies when to use this tool (e.g., before posting to check readiness) but does not explicitly state when to use it vs alternatives or when not to use it. No comparative guidance 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?

No annotations exist, so description carries full burden. It states read-only and no switch, but lacks details on return format, error behavior, or what happens if no identity is set. Adequate but could be more comprehensive.

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

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

A single concise sentence that front-loads the action and purpose. No wasted words, earning 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 zero-parameter read-only tool with no output schema, the description is largely complete. It explains what it does and why useful. Could mention output format but not critical.

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

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

No parameters (100% coverage), baseline 4. The description adds value by explaining the purpose and read-only nature, going beyond just the schema.

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

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

The description clearly states the tool reads which Facebook page/profile the browser tab currently posts as, using specific verb 'Read' and resource 'identity'. It distinguishes from sibling tools like switch_profile by noting 'no switch'.

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

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

The description provides a clear use case: 'Useful to confirm identity before posting.' It implies when to use but does not explicitly mention when not to use or alternative tools, though sibling switch_profile contrasts implicitly.

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 lists what is checked but does not disclose behavioral traits such as idempotency, side effects, or authentication requirements. It is likely a safe read operation but not explicitly stated.

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

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

The description is a single concise sentence that front-loads the purpose. However, the list of checks is run-on and could be more structured for readability. No fluff.

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

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

The tool has no output schema, yet the description does not describe the return format (e.g., boolean fields or status object). This omission leaves the agent uncertain about what to expect from the tool's output.

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 zero parameters in the input schema, so the description does not need to add parameter semantics. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter information.

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

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

The description clearly states the tool's purpose: checking the health of the bridge and Chrome extension, including specific aspects like template capture status and tab freshness. This distinguishes it from sibling tools like capture_status which focus on individual template status.

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

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

The description implies usage for health checks but does not explicitly state when to use this tool versus alternatives like capture_status or get_identity. No when-not guidance is provided.

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

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

With no annotations, the description carries full burden. It discloses the browser extension mechanism, prerequisites, and single vs. album behavior. No mention of side effects or rate limits, but core behavioral context is provided.

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

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

Two sentences, no filler. First sentence states action and method, second lists requirements. Efficient and front-loaded.

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

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

Lacks return value explanation (no output schema) and per-parameter detail. Prerequisites are covered, but the agent lacks information on what happens after posting.

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

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

The description adds minimal parameter meaning: image_paths can be 1 or N images. Other parameters (caption, page_id, scheduled_publish_time) are not explained. With 0% schema coverage, the description fails to compensate.

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

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

The description clearly states the tool publishes a Facebook photo or album using the browser extension, distinct from the Graph API. It differentiates from sibling tools like post_reel by specifying 'photo' vs '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?

The description lists prerequisites: bridge running, logged-in tab, captured template. It implicitly suggests using capture_status first. However, it does not explicitly state when not to use it or compare to alternatives beyond 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 description carries full burden. It discloses the use of native web API to avoid reach suppression, but omits details on failure modes, idempotency, or state changes. Adequate but not comprehensive.

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 purpose and method, followed by requirements. No unnecessary words or redundancy. Highly efficient.

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

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

Given 4 parameters, no output schema, and no annotations, the description covers the core action and prerequisites but leaves parameter specifics and return values unexplained. Adequate for basic understanding but incomplete.

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

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

Schema coverage is 0%, yet the description only indirectly references video_path and caption via 'local .mp4' and 'caption'. It provides no details on page_id or scheduled_publish_time. Does not compensate for the lacking schema descriptions.

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

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

The description clearly states the tool publishes a Facebook Reel from a local .mp4 via the browser extension, specifying the mechanism (native web API) and differentiating from siblings like post_photos or capture_status.

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

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

The description explicitly lists prerequisites: bridge running, logged-in facebook.com tab, and a captured reel template (referencing capture_status). It implicitly suggests when to use but does not name alternatives or specify when not to use.

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

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

With no annotations, the description carries the full burden. It discloses the effect on subsequent posts and the requirement of a mutation template, but does not explain what happens if the template is missing or if switching back is possible. For a simple state-changing tool, this is adequate but not comprehensive.

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

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

The description is two sentences, both front-loaded with the core purpose and effect. The second sentence adds a key prerequisite. No wasted verbiage, but it could be slightly more structured (e.g., separating the requirement).

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

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

For a tool with one parameter, no output schema, and no nested objects, the description covers the essential aspects: what it does, the effect on sibling tools, and a prerequisite. It is nearly complete for its simplicity, though it could clarify the exact behavior of switching (e.g., whether it's reversible).

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

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

The schema has one parameter (target_id) with 0% description coverage. The tool description adds meaning by specifying it is a 'Facebook page/profile id', which clarifies the parameter's purpose beyond the schema's generic title 'Target Id'. However, it does not describe the format or how to obtain the id, leaving some ambiguity.

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

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

The description clearly states the action ('Switch the browser session'), the target ('Facebook page/profile id'), and the effect ('subsequent post_reel / post_photos go out AS that page'). It distinguishes from sibling tools like post_photos and post_reel by indicating this tool is used to set the identity for those operations.

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

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

The description explains when to use the tool (before posting as a page) and explicitly mentions a prerequisite ('Requires a captured CometProfileSwitchMutation template'). However, it does not provide exclusions or alternative tools for switching profiles, though the sibling context makes the usage fairly clear.

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