Skip to main content
Glama

Facebook Profile Events

social_facebook_profile_events
Read-only

Get the events of a public Facebook page Completed lookups cost at least 10 Nexscope credits. Actual cost depends on the operation and requested options. Repeated requests may purchase data again. Facebook Profile Events API View Pricing Get the events of a public Facebook page 1 credit per request Actual supplier units are reported per request. Examples are not guaranteed prices.

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL of the public Facebook page
cursorNoThe cursor to paginate to get more events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the description only needs to add context. It attempts to disclose cost but is internally contradictory, saying 'Completed lookups cost at least 10 Nexscope credits' and later '1 credit per request', and warns of repeated purchases without clarifying, which actively confuses rather than informs.

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

Conciseness2/5

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

The first sentence is duplicated, and the bulk of the text is vendor pricing and marketing boilerplate ('View Pricing', 'Actual supplier units are reported per request', 'Examples are not guaranteed prices') that is not front-loaded useful content.

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

Completeness2/5

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

For a paginated, credit-metered lookup with no output schema, the description leaves critical things unclear: whether pagination is required to get all events, how credits are actually charged, and what the response contains. The price statements contradict each other, so an agent cannot reliably reason about cost.

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%, with both 'url' and 'cursor' documented in the schema. The description adds nothing about the URL format expected for public pages or about how the pagination cursor is used, so the baseline of 3 applies.

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

Purpose3/5

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

The sentence 'Get the events of a public Facebook page' states a verb and resource, but it is repeated verbatim twice and never distinguishes this tool from sibling tools like social_facebook_events, social_facebook_events_search, or social_facebook_event_details, so an agent cannot tell which of the near-identical event tools to pick.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only extra content is pricing boilerplate, which does not help an agent decide between this tool and its Facebook event siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.