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 that the value is UTC, where account credentials live (~/.facebook-mcp/accounts/<account>/), and that the account defaults to the configured one, but it says nothing about auth failures, private/nonexistent users, 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?

Three compact sentences, front-loaded with the resource and return value before the input-format and account caveats. 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?

An output schema exists, so return-value details need not be repeated, and both parameters are covered. The only gap is behavior on failure cases (unknown user, private profile), which is minor for a simple read-only lookup.

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%, so the description must carry the parameter meaning, and it does: it specifies the username format (no URL, no leading '@') with an example, and explains that account selects the credential set under ~/.facebook-mcp/accounts/<account>/ and defaults to the configured account.

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: the publish time (UTC) of a user's latest post, keyed by username. The 'latest post' scoping implicitly distinguishes it from the sibling get_user_recent_posts.

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 by the 'latest post' phrasing; there is no explicit statement of when to pick this over get_user_recent_posts or any other sibling. It does give input-format guidance (username, account), but that is parameter help rather than when/when-not 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?

With no annotations, the description carries the full burden. It usefully discloses ordering (newest first) and the credential-set semantics of the account path plus its default, but says nothing about auth requirements, rate limits, or failure behavior when an account is absent.

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 primary action and return contents. The second sentence is long but each clause carries real information about account resolution.

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?

An output schema exists so return values need not be restated, and the description does cover ordering and account resolution. However, with no annotations and 0% schema coverage it leaves the limit parameter and any failure/edge behavior undocumented.

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%, so the description must compensate. It does explain the account parameter well (credential set under ~/.facebook-mcp/accounts/<account>/, default configured account), but limit and its default of 10 go entirely unexplained in both schema and 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 (List) and resource (a user's recent posts) plus ordering and the fields returned, which implicitly separates it from get_user_latest_post_time. It never names that sibling explicitly, so the differentiation is left for the agent to infer.

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 conditions, and no mention of the obvious alternative get_user_latest_post_time. The only contextual remark is about the account default, which is parameter behavior rather than usage 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 carries the full behavioral burden. It does disclose meaningful traits — a logged-in session is required and which credential set gets selected — but says nothing about pagination, rate limits, or failure behavior, and 'search' gives no indication of read scope beyond the implicit 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?

Three sentences, front-loaded with the purpose, then prerequisite, then the optional parameter detail. No filler, though the ~/.facebook-mcp/accounts/<account>/ path spelling is verbose for what it conveys.

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?

An output schema exists, so return values needn't be explained, and the auth prerequisite is covered. The notable gap is the undocumented 'limit' parameter, which appears in neither the description nor the schema, and no indication of how many results or pagination behavior to expect.

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%, so the description must compensate. It documents 'q' (with an example) and 'account' (credential path plus default), which is worthwhile, but 'limit' is never mentioned and neither 'q' nor 'account' syntax is fully specified beyond the example.

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 ('Search Facebook pages by keyword') and gives a concrete example query. The resource 'pages' implicitly separates it from search_people, but the description never names that sibling or other alternatives, so differentiation is left 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 purpose plus the stated prerequisite ('Requires a logged-in session'), but there is no explicit when-to-use/when-not guidance and no pointer to alternatives like search_people for a different entity type.

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 auth requirement (logged-in session) and how credentials resolve via ~/.facebook-mcp/accounts/<account>/ with a configured default. Beyond that it says nothing about result volume, pagination, or rate limits, so disclosure is partial.

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, front-loaded with purpose, then prerequisites and the optional account detail. Nothing is wasted, though the long filesystem path could be trimmed for readability.

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?

An output schema exists, so return values need not be explained. Purpose, auth prerequisite, and account selection are covered; the only gap is the undocumented 'limit' parameter and any result-count behavior, which is minor for this 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 coverage is 0%, so the schema provides no parameter documentation. The description does compensate for 'account' by explaining its credential-directory semantics and default, and it illustrates 'q' with an example, but 'limit' is entirely unaddressed despite its default of 10.

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 ('Search Facebook people by keyword') and reinforces it with a concrete query example. It implicitly distinguishes itself from the sibling search_pages, but never names that alternative to remove the ambiguity between searching people vs pages.

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 context is implied by the resource ('Search Facebook people') and a prerequisite is stated ('Requires a logged-in session'), but there is no explicit statement of when to choose this over search_pages or the get_user_* siblings, 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 provided, so the description carries the full behavioral burden. It usefully discloses the auth/transport prerequisite and where account credentials live, which is real context the schema cannot express. But for a mutation (message-send) tool it omits delivery semantics — immediacy, failure modes, rate limits, or irreversibility — leaving the behavioral picture incomplete.

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?

Front-loaded with the core action, then recipient syntax, then prerequisites and account default — a logical ordering with little waste. It is slightly verbose (three clauses on transport/account paths) but each clause conveys usable 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?

An output schema exists, so return values need not be described, and the description covers prerequisites, recipient formats, and account selection for a 3-parameter tool. The remaining gap is mutation-side behavior (rate limits, failure handling), which keeps it short of fully complete.

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%, so the description must compensate and largely does: it explains that 'recipient' accepts a numeric uid, username/vanity, or profile URL, and that 'account' selects a credential set under ~/.facebook-mcp/accounts/<account>/ and defaults to the configured account. Only 'text' is left undocumented, but its meaning is self-evident.

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 concrete verb+resource ('Send a Messenger message to a user or page'), leaving no ambiguity about the operation. It does not reference any sibling tool, but the action is inherently distinct from the read-only siblings (search_people, get_user_recent_posts), so differentiation is implicit 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 description gives prerequisites ('Requires a logged-in browser (FB_TRANSPORT_MODE=auto or cdp)') which effectively tells the agent when the tool can be invoked. However, it never states when to prefer this over alternatives, nor any exclusions (e.g., unsolicited/spam messaging limits or rate limits). Usage is only implied by the tool's obvious purpose.

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