Usage and limits
How billing and credits work?
Sociality MCP uses credits to keep usage predictable across account, competitor, and post-level workflows. This section explains how credits are counted, which operations use credits, and how data access, result limits, and safeguards work across Sociality MCP.
Usage and limits
Credit model
Sociality MCP uses a simple credit model based on returned value. One credit maps to one unit of data returned by a request.
1 credit =
- One day of account metrics
- One day of competitor insights
- One post with full details
In daily use, this means:
- If you generate a daily account report for April, the query returns one result for each day and uses 30 credits. If you run the same daily query for one competitor page, it also uses 30 credits.
- If you request posts for a selected period, credit usage depends on the number of posts returned. For example, 18 returned posts use 18 credits.
This keeps credit usage predictable across account reporting, competitor benchmarking, post analysis, and custom agent workflows.
Usage and limits
Billable operations
Some MCP operations consume credits when they return data. Others do not consume credits and can be used for setup, discovery, workflow preparation, or supported write actions.
| Operation | Credit usage | Includes |
|---|---|---|
| Account stats | Yes | social_account_stats_list |
| Account posts | Yes | social_account_posts_list |
| Competitor stats | Yes | social_competitor_stats_list |
| Competitor posts | Yes | social_competitor_posts_list |
| Account list | No | social_accounts_list |
| Competitor list | No | social_competitors_list |
| Competitor creation | No | social_competitors_create |
| Resources | No | social_workspace_context, social_tools_catalog, social_platform_capabilities |
| Prompts | No | social_guide_tool_usage, social_guide_readiness_check |
social_competitors_create does not consume credits, but it is a write action and remains subject to workspace permissions and plan limits.
Usage and limits
Current usage
Use social_workspace_context to check current MCP credit usage, limit, and resets_at before running larger, recurring, or automated workflows.
This helps you confirm available credits before starting workflows that may return more data than a quick setup check.
Usage and limits
Result limits
List tools return up to 50 rows per page.
Stats and posts tools return up to 50 rows per call. For larger result sets, use pagination where supported, narrow the date range, or apply filters before expanding the query.
Tool and resource responses can include an _envelope block with response metadata such as versioning, server timestamp, cache TTL, and warnings.
Usage and limits
Data retention
Data retention determines how far back Sociality MCP can access stored account and competitor data. Historical availability can depend on the source platform, data type, connected account state, and plan.
At the start of a paid subscription, Sociality backfills data up to the included retention period. Some older data may be unavailable because platforms do not always provide every metric or post type retroactively. For example, certain daily metrics, such as followers, may not be available for past dates on some platforms. Time-sensitive post formats, such as stories, may also be unavailable after they expire.
After setup, available data is collected continuously while the subscription remains active. The Starter plan includes 30 days of data retention, Growth includes 12 months, and Scale can include extended retention based on your needs.
Usage and limits
Usage safeguards
Users, pages, and competitors are not capped by fixed plan limits, but access still needs to stay reasonable, reliable, and aligned with the intended use of Sociality MCP.
Usage may be reviewed when activity is unusually high, automated in a way that affects service reliability, or appears inconsistent with normal account, competitor, or post-level workflows. Activity may also be limited when it creates compliance, platform-policy, or acceptable-use concerns.
If needed, safeguards such as temporary limits, request throttling, or plan adjustments may be applied to protect platform stability and ensure fair access for all users.