meta-business-insights-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear distinctions: portfolio discovery vs. insights, Facebook vs. Instagram, and current vs. historical follower data. However, multiple tools (list_portfolio, followers_overview, and followers_timeseries) all provide follower counts, which could cause selection confusion for agents seeking current totals.
Naming Consistency3/5
The naming mixes conventions: list_* for listing, *_insights for metrics, and noun phrases like followers_overview and snapshot_history. While the prefixes make some patterns identifiable, there is no consistent verb-noun structure across the set.
Tool Count5/5
9 tools is a reasonable, well-scoped count for a Meta business insights server. It covers essential operations—portfolio discovery, follower snapshots/timeseries, page and Instagram insights, metric catalogs, and local history—without unnecessary redundancy.
Completeness4/5
The set covers the core domain: asset discovery, follower data (current, aggregated, historical), platform-specific organic insights, and a metric catalog with deprecated replacements. The raw graph_api_get and local snapshot mechanism fill gaps, but ad-related insights are not explicitly included.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only mentions aggregation and gives examples. It doesn't cover that this is a read-only operation, that certain metrics require timeframe/breakdown, rate limits, or what happens with empty assets. The phrase 'orgânicas' is useful context but insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, no filler.
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?
The tool has 10 parameters and no output schema, so the description should at least hint at return structure or usage caveats. It doesn't mention that groupBy controls output shape, that some metrics need timeframe, or how deltas appear. This leaves the agent under-informed for a relatively complex tool.
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 detailed parameter descriptions, so the schema already handles parameter semantics. The description adds a few metric-name examples but no additional syntax or relationships beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing organic metrics for portfolio Instagram accounts, aggregated by period/account, and gives relevant examples. It doesn't use an explicit verb like 'retrieve' but the resource and scope are unambiguous. It does not explicitly distinguish from sibling tools like page_insights or followers_overview, but the focus on organic metrics and aggregation is fairly specific.
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?
No guidance is provided about when to use this tool versus alternatives such as page_insights, followers_overview, or graph_api_get. The description gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that metrics are aggregated in user-defined ways but does not explicitly mention the read-only nature, data limitations, or output format. The description is essentially a noun phrase, leaving important behavioral traits like whether it returns raw or processed data, or whether any side effects exist, implicit.
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?
The description is concise: one sentence plus a list of relevant examples. It is front-loaded with the core purpose, and the example metrics are useful without adding unnecessary detail. It earns its place, though it could be slightly more explicit about the action.
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?
With 9 parameters and no output schema, the description is relatively sparse. It does not describe the structure of the returned data, pagination, or any operational constraints. The rich schema compensates for parameter understanding, but the lack of output context makes it harder for an agent to anticipate the result format and overall tool behavior.
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 description coverage is 100%, so the baseline is 3. The description adds some value by giving example metrics (page_follows, page_views_total) and aggregation contexts (month, account, portfolio), but it does not materially enhance understanding beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Facebook Pages organic metrics with flexible aggregation options (by month, account, or portfolio) and gives concrete examples. It distinguishes itself from sibling tools like instagram_insights by explicitly focusing on Facebook Pages, but it lacks a direct action verb such as 'retrieves' or 'lists', making it a noun-phrase description rather than a clear statement of what the tool does.
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?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it name any sibling tools or describe exclusions. The specificity to 'Facebook Pages' and 'organic metrics' implies usage contexts, but without explicit before/after guidance, an agent may be unsure which insights tool to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses a key behavior: includes organic and paid growth because it uses the real account number. However, it does not explicitly state whether the operation is read-only, mention rate limits, or describe data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the snapshot purpose, and every clause adds value. It is free of redundant information and fits the tool's simple scope.
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?
The description explains the core return value (followers per asset and consolidated) and the organic+paid growth nuance, which is sufficient given the low complexity and optional single parameter. However, the absence of an output schema or annotations means some details like exact output structure are not covered.
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% because the 'assets' parameter already includes a descriptive definition (IDs or account names, empty = whole portfolio). The description adds no further parameter-specific semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a current snapshot ('Foto do momento') of total followers per asset and consolidated portfolio (Facebook + Instagram). It implicitly distinguishes from followers_timeseries by emphasizing the present moment, though it does not explicitly name alternatives.
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?
The description implies use for obtaining immediate follower counts, but does not explicitly state when to prefer this tool over followers_timeseries or page_insights. There are no exclusions or alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight for behavioral disclosure. It states it writes to local history but does not disclose side effects like whether repeated saves on the same date overwrite or append, what happens on duplicate dates, authentication requirements, or failure behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and object, the second provides clear rationale. No filler or redundant information, making it highly efficient.
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 write tool with no annotations or output schema, the description omits key contextual details: idempotency (what happens if run twice for the same date), how the snapshot is stored, and whether it returns anything. The existence of sibling snapshot_history implies a complementary tool but no link is made. The rationale is helpful but not sufficient for a complete operational picture.
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 description coverage is 100%, so the baseline is 3. The description does not add parameter detail beyond the schema, and the phrase 'todos os ativos' slightly conflicts with the assets parameter that allows filtering to a subset, introducing minor ambiguity.
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?
The description clearly states the tool's function: 'Grava o total de seguidores de todos os ativos em um histórico local' (records total followers in a local history). This distinguishes it from sibling tools like graph_api_get and snapshot_history, and the mention of building a long series adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use it: because the Graph API only returns 30 days of history, running this periodically builds a long-term series. However, it does not name specific alternative tools or conditions where it should not be used, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses meaningful behavioral context: it combines organic+paid data, covers both Facebook and Instagram, allows per-asset or portfolio consolidation, and computes gains/losses/balance/accumulated total. However, it does not disclose return format, auth needs, rate limits, or edge cases, leaving moderate gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and key options. Every word adds value: metrics, granularity, data mix, platform coverage, and aggregation mode. No filler or redundancy, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 optional parameters and no output schema, so the description must explain return values. It does explain the conceptual output (gains, losses, balance, cumulative) but not the actual response structure, pagination, or how periods are keyed. It lacks enough detail to fully predict the tool's behavior in all contexts.
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 description coverage is 100%, so all parameters are already explained in the schema. The description adds some context by mentioning granularity and consolidation options, but it does not provide new syntax or format details beyond the schema. The baseline of 3 applies; the description reinforces but does not significantly augment parameter semantics.
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?
The description clearly states a specific verb+resource: it shows follower evolution over time with metrics like gains, losses, balance, and cumulative totals. It also distinguishes itself by specifying scope (Facebook/Instagram, per asset or consolidated) and granularity (month/day/week/quarter/year), differentiating it from sibling tools like followers_overview or snapshot_history.
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?
The description implies usage by describing the time-series analysis, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. There is no comparison to sibling tools like followers_overview or snapshot_history, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It transparently frames the tool as a read-only catalog, avoiding any implication of mutating data. Mentioning the map of discontinued metrics and substitutes adds context beyond a simple list, though output format and pagination are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose (catalog of metrics) and adds the key nuance about discontinued metrics. No redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description is serviceable but not fully complete. It explains the scope and special feature (discontinued metrics), but omits how the surface parameter affects results and what the catalog entry structure looks like, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the 'surface' parameter, so it does not add meaning beyond the schema's enum/default. The description's mention of 'Page e Instagram Insights' loosely aligns with the surface values, but does not explain how to use the parameter to filter the catalog.
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?
The description clearly identifies the tool as a catalog of organic metrics for Page and Instagram Insights, also covering discontinued metrics and their substitutes. This distinguishes it from sibling tools that focus on actual metric values (e.g., page_insights, followers_overview). The purpose is specific and actionable.
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?
The catalog nature implies use when an agent needs to know available metrics or understand Meta's discontinued metrics and replacements, but no explicit when-to-use or when-not-to-use guidance is provided. It does not mention alternatives by name, relying on the sibling list to convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly states the returned data (IDs and follower total) but does not explicitly disclose that this is a read-only operation, caching behavior, or any side effects. The schema description covers the cache, but the description itself lacks that context. For a simple list operation, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence defines the purpose, and the second provides usage context. Every word earns its place.
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?
The tool is simple (one optional param, no output schema), and the description covers the core purpose, the data returned, and how to use it in the workflow. It could mention the refresh parameter or the cache, but the schema handles that, so it is complete for its complexity.
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 the single `refresh` parameter documented with its meaning (ignores 10-minute cache). The description does not discuss parameters, but the schema fully compensates, so the baseline of 3 is appropriate.
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?
The description uses the specific verb 'Lista' and clearly identifies the resource: all Facebook Pages and Instagram accounts in the portfolio (Business Manager), including IDs and follower count. It also differentiates itself from sibling tools by explicitly stating it is meant to discover IDs for other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool 'antes das outras tools' to discover IDs, providing clear when-to-use guidance. However, it does not name alternatives or state when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool reads local snapshots and avoids the Graph API's short window, but it does not mention potential empty results, data freshness, or output format. This adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence efficiently conveys purpose and key differentiator without any fluff. Every clause earns its place.
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?
The description explains the data source, the producing sibling tool, and the key advantage over the Graph API. While there is no output schema or explicit return format, the phrase 'série de seguidores' sufficiently indicates a time series, making the tool understandable.
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 description coverage is 100%, so parameters are already fully documented. The description adds no parameter-specific information, earning the baseline score of 3.
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?
The description uses a specific verb 'Lê' (reads) and identifies the resource as the local follower series recorded by save_followers_snapshot. It clearly distinguishes from Graph API-dependent tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'sem depender da janela curta da Graph API' provides clear context for when to use this tool (to access historical data without API limitations), though it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context about token resolution ('com o token certo já resolvido'), but it does not explicitly mention read-only semantics, error behavior, or rate limits. GET semantics imply safety, but more detailed disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action verb and resource, with no redundant information. Every word contributes to understanding the tool's function and usage context.
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?
As a generic fallback tool, the description adequately covers purpose, when to use, and token handling. It lacks explicit mention of response format, but given the open-ended nature of the tool and the absence of an output schema, this is less critical. The pagination parameter is documented in the schema.
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 description coverage is 100%, and each parameter has a description. The description itself adds little beyond the schema, though the note about token resolution provides relevant context for how authentication is handled. With schema doing the heavy lifting, a baseline of 3 is appropriate.
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?
The description uses a specific verb ('Chamada GET direta') and resource ('qualquer nó/edge da Graph API'), clearly identifying this as a raw GET endpoint. It distinguishes from siblings by framing it as a fallback for metrics not covered by other tools, which makes 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use quando a métrica ou campo desejado não estiver coberto pelas outras tools.' This provides clear context and implies that specialized sibling tools are preferred when applicable, even though it doesn't list specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![meta-business-insights-mcp MCP server](https://glama.ai/mcp/servers/kenjimattos/meta-business-insights-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kenjimattos/meta-business-insights-mcp)

Score Badge

Copy to your README.md:

[![meta-business-insights-mcp MCP server](https://glama.ai/mcp/servers/kenjimattos/meta-business-insights-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kenjimattos/meta-business-insights-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kenjimattos/meta-business-insights-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server