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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely useful behavior beyond them: credit cost per completed lookup, the warning that repeated requests may purchase the data again (billing non-idempotency), that creation_time can be null, and that rental listings may expose listing_date_text/availability_text. It is weakened by an internal inconsistency, stating 'at least 10 Nexscope credits' in one place and '1 credit per request' in the pasted supplier text, which leaves the actual cost ambiguous.

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 useful first three sentences are followed by pasted marketing boilerplate that repeats the tool name and purpose ('Facebook Marketplace Marketplace Item API View Pricing Get a Facebook Marketplace item...') and repeats pricing in a contradictory way. Roughly half the text does not earn its place and actively muddies the cost signal.

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 carries the burden of describing the return payload and does so by listing the main fields plus rental-specific fields and null-timestamp caveats. What is missing is the input contract (one-of id/url, precedence) and a resolved cost figure, but for a read-only single-item lookup the coverage is otherwise solid.

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 (id, url) are already documented, and the description's 'by item id or Marketplace item URL' merely restates them. It does not clarify the important gap that the schema lists no required parameters, so an agent gets no confirmation that at least one of id or url must be supplied, nor which takes precedence if both are given.

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 and resource: 'Fetches details for a Facebook Marketplace item by item id or Marketplace item URL', then enumerates the returned fields (title, price, location, condition, photos, seller, availability). This is clearly a single-item lookup, distinguishable from the sibling search tools social_facebook_marketplace_search and social_facebook_marketplace_location_search 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?

Usage is only implied: an agent infers it should call this once it has an item id or URL. There is no explicit guidance that the id/URL must come from a prior marketplace search, no statement about which parameter wins when both are supplied, and no when-not-to-use note relative to the search siblings.

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