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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and data openness. The description adds the nuance that both URL and username are accepted (though the schema only mentions URL), which is a small behavioral detail. However, it does not mention authentication requirements, rate limits, or what happens if the profile is inaccessible. Given the annotation coverage, the description adds modest value, warranting a 3.

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 communicates the core action and input method without any filler. It front-loads the purpose and avoids unnecessary elaboration, making it highly efficient for an agent to parse.

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 a simple signature with two optional parameters and lacks an output schema. The description explains what it does and how to call it, but does not disclose the shape of the response (e.g., what profile fields are returned). While a profile getter typically returns standard fields, the absence of any indication about return content or potential errors (e.g., non-existent profiles) leaves a gap in completeness. Given the low complexity, a 3 is appropriate—it is functional but could be more informative.

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 covers 100% of parameters, both with descriptions. The tool description enriches the 'url' parameter by stating that a username is also acceptable, which is not captured in the schema's parameter description ('Facebook public profile or page URL'). This additional semantic guidance aids the agent in accepting username values, elevating it above the 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?

The description clearly states the action ('Get') and the resource ('Facebook profile or Page'), and specifies the input method ('by URL or username'). It distinguishes this tool from sibling list tools like facebook_profile_posts_list and facebook_profile_photos_list by focusing on the core profile/page entity, making its purpose 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?

The description implies its usage context: it is the primary tool to fetch a Facebook profile or page's basic information. While it does not explicitly contrast with siblings, the tool name and surrounding siblings (e.g., facebook_profile_posts_list) make it clear that this is for the profile itself, not its lists. The mention of 'public' hints at access scope, but no explicit when-not or alternative routing is provided, so a slight deduction from 5 is warranted.

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