Skip to main content
Glama
Sign In
facebook-mcp

facebook-mcp

by IvanBBaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Page

facebook_get_page
Read-onlyIdempotent

Fetch a Facebook Page's metadata—name, category, follower/fan counts, publish state—and optionally public business profile fields like hours, website, phone, and address using a profile key or Page ID.

Instructions

Fetch metadata for one Page — name, category, follower/fan counts, publish state and new-Page-experience flag. field_set:"profile" also returns the public business fields: about, description, website, phone, emails, hours (as [{day, open, close}] ranges), is_always_open, temporary_status, single_line_address and location. Accepts an optional profile key or Page ID; omitted ⇒ the default Page.

Input Schema

NameRequiredDescriptionDefault
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).
field_setNo"summary" (default): identity, counts and publish state. "profile": the summary plus the public business fields (hours, website, phone, address, …).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / field_set
      Added value: +{
+  "description": "\"summary\" (default): identity, counts and publish state. \"profile\": the summary plus the public business fields (hours, website, phone, address, …).",
+  "enum": [
+    "summary",
+    "profile"
+  ],
+  "type": "string"
+}
  2. First observedv0.7.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare the safe, idempotent, open-world read profile, so the description focuses on the useful extras: the omitted-argument fallback to the default Page and the concrete shape of the hours field ("[{day, open, close}] ranges"). It stops short of noting permission requirements or error behavior for an unknown profile key.

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

Conciseness4/5

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

Two sentences, front-loaded with the core purpose, with the field inventory following. The inline field enumeration is long but earns its place since no output schema exists; minor cost is that the parameter rule is buried at the end.

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

Completeness4/5

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

With no output schema, describing the returned fields carries real weight and is done well, and the default-Page behavior is documented. Gaps are small: no mention of failure modes for an invalid Page ID or of what `publish state`/`new-Page-experience` actually mean as values.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented in the schema; the description largely restates `field_set` semantics and the default-Page fallback. It adds only marginal meaning, such as the concrete hours range structure, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ("Fetch metadata for one Page") and enumerates the exact fields returned, which separates it from the sibling facebook_list_pages. An agent can tell this is a single-object read versus a collection listing 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.

Usage Guidelines3/5

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

Usage is only implied: the description explains what each `field_set` value yields, which nudges selection between summary and profile, but it never states when to reach for this tool over siblings like facebook_list_pages, facebook_page_insights or facebook_whoami. No exclusions or prerequisites are given.

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

Deploy Server

Other Tools