flin-meta-ads-mcp

Server Quality Checklist

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

Latest release: v0.1.10
Disambiguation5/5
Each tool targets a distinct entity and action: get/list for ad accounts, campaigns, adsets, ads, ad images, and ad creatives, plus dedicated preview and insights tools. There is no overlap or ambiguity between the tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase and underscores, with the verbs 'list' for collections and 'get' for single entities. This makes the tool surface predictable and easy to navigate.
Tool Count5/5
With 14 tools, the server is well-scoped for a read-only Meta Ads API. The count covers all major resources without being overwhelming or too sparse.
Completeness4/5
The server provides comprehensive read coverage for all major objects (accounts, campaigns, adsets, ads, images, creatives, preview, insights). The only noticeable gap is the lack of write operations (create/update/delete), but the server appears intentionally read-only based on the tool descriptions.
Average 3.1/5 across 14 of 14 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description says nothing about behavioral aspects like pagination, return format, rate limits, or required permissions. It only restates the basic action of listing ad sets, which provides no additional transparency beyond the name.
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, focused sentence that fully states the core purpose without any unnecessary words. It is optimally concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters, no output schema, and no annotations, yet the description provides no context about the ad account structure, filtering options, or list behavior. The description is far too minimal to be considered complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (after, limit, fields, ad_account_id, effective_status). The description adds zero value for understanding how to use the parameters.
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 listing ad sets for an ad account, using a specific verb ('list') and a clear resource ('ad sets'). It distinguishes from siblings like list_campaigns and get_adset by resource name, but doesn't explicitly contrast with alternatives.
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 guidance on when to use this tool versus alternatives such as get_adset or list_campaigns. The description provides no context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the tool's name and sibling names.
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 must carry the burden of behavioral disclosure, but it only restates the list action. It does not mention pagination behavior via 'after'/'limit', default limits, field selection, or filtering by effective_status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. However, the brevity comes at the expense of necessary detail for a tool with five parameters, making it under-specified rather than appropriately concise.
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?
Given no output schema, no annotations, and a five-parameter input schema, the description is too sparse. It fails to explain pagination, field selection, status filtering, or response shape, leaving the agent with insufficient information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the five parameters. Parameter names like 'effective_status', 'after', and 'fields' are left unexplained, so the description adds no meaningful semantics beyond the raw schema.
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 uses a specific verb ('List') and resource ('campaigns') with scope ('for an ad account'), making the core purpose clear. It differentiates from the singular 'get_campaign' and other list tools by naming the resource, though it does not explicitly contrast with alternatives.
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 on when to use this tool versus alternatives like get_campaign, list_ads, or list_adsets. The phrase 'for an ad account' gives context but is not a usage criterion or exclusion.
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 must convey behavior, but it only says 'list ad accounts accessible by the token.' It does not disclose pagination behavior, whether it is read-only, or what happens with parameters like 'after' and 'limit'. 'List' implies a safe operation, but no explicit safety guarantee is given.
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 a single concise sentence with no filler words, front-loading the key action and resource. However, it is so brief that it omits useful context, but that is more a completeness issue than a conciseness one.
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?
Given the tool has 5 parameters, no annotations, and no output schema, the description is inadequate. It does not explain pagination, field selection, or status filtering, nor does it describe the return format. It provides only the bare minimum statement of purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions none of the 5 parameters. There is no explanation for 'after', 'limit', 'fields', 'ad_account_id', or 'effective_status', leaving the agent to infer their roles solely from names. The description adds no value beyond the schema.
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 'List' with the resource 'ad accounts' and further qualifies it with 'accessible by the token', clearly distinguishing it from the singular 'get_ad_account' sibling. This makes the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_ad_account or list_campaigns. It only implies 'use this to list ad accounts,' but does not mention exclusions or conditions, leaving the agent without decision support.
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?
The description only says 'List', which implies a non-mutating read, but provides no behavioral details beyond that. With no annotations provided, the description carries the full burden but fails to mention pagination, authorization requirements, or any side effects.
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 concise sentence that avoids fluff and directly states the operation. It is front-loaded with the verb and resource, making it easy to scan, though the brevity limits other aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, this description is far from complete. It omits essential context like filtering via 'effective_status', field selection via 'fields', and pagination through 'after' and 'limit', leaving the agent with insufficient information to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and none of the 5 parameters ('after', 'limit', 'fields', 'ad_account_id', 'effective_status') are explained in the description. The tool's actual filtering and pagination capabilities are entirely undocumented.
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 ('List') and resource ('ad creatives') with scope ('for an ad account'), clearly distinguishing it from sibling tools like 'get_ad_creative' (single retrieval) or 'list_ad_images' (different resource). The purpose is immediately understandable.
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 on when to use this tool compared to alternatives such as 'list_ads' or 'get_ad_creative'. There is no mention of exclusions, prerequisites, or typical scenarios.
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?
Annotations are absent, and the description only states 'Fetch a single ad image by id', which adds little beyond the tool name. It does not disclose return format, error behavior, permissions, or other operational characteristics.
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 a single short sentence, highly compact and front-loaded. It is free of redundancy, though its brevity leaves room for more substance.
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 no annotations, no output schema, and only a minimal description, the tool lacks essential context for correct selection and invocation. Sibling tools exist but are not differentiated, and parameter details are missing.
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 coverage is 0%, so the description must compensate. It only implicitly covers the 'id' parameter but completely omits the 'fields' parameter, leaving half the interface unexplained.
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 'Fetch' and resource 'ad image' with 'by id', clearly indicating it retrieves a single image entity. This distinguishes it from sibling tools like list_ad_images (list operation) and get_ad_creative (different resource).
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 on when to use this tool versus alternatives such as list_ad_images, get_ad, or get_ad_creative. There is no mention of exclusions, use-case context, 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?
With no annotations, the description must carry the burden of disclosing behavior. It only says 'list' which implies a read operation, but it does not mention pagination, response format, field selection, or any access requirements, leaving behavior largely unspecified.
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 single sentence is concise and front-loaded, with no unnecessary words. It effectively communicates the core purpose in minimal space.
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 tool with five parameters and no output schema or annotations, the description is inadequate. It does not cover return values, pagination, filtering, or the meaning of the parameters, leaving significant gaps for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the five parameters (after, limit, fields, ad_account_id, effective_status). There is no additional meaning added beyond the parameter names and types.
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 operation (list) and resource (ads) with a scope (for an ad account), making its purpose unambiguous. It differentiates from sibling tools like list_campaigns and list_adsets by specifying the resource type.
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 on when to use this tool versus alternatives like get_ad for a single ad or list_adsets for ad sets, nor are any prerequisites or filtering recommendations mentioned.
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 only states a basic fetch operation and does not mention read-only semantics, error handling (e.g., not found), the effect of the optional 'fields' parameter, or any rate limits. This is a significant gap for a tool with no annotation support.
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, front-loaded sentence that immediately communicates the tool's core purpose. There is no wasted wording or unnecessary detail, making it highly concise and well-structured.
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?
Given there is no output schema and no annotations, the description should explain what is returned and any error behavior, but it does not. It also lacks details about the optional 'fields' parameter and how it affects the response. For a simple getter, the description is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It mentions 'id' in a generic way but does not explain the ID format (numeric pattern), the purpose of the optional 'fields' array, or how the parameters interact. The description adds no meaningful semantic value beyond what the schema already provides.
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 'Fetch a single ad by id' clearly states the action (fetch), resource (a single ad), and scope (by id), distinguishing it from sibling tools like list_ads (plural) or get_ad_image (different resource type). It is specific and unambiguous.
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 when a single ad is needed by ID, but it does not explicitly mention when not to use it or point to alternatives like get_campaign or list_ads. This is implied usage rather than no guidance, but it lacks clear exclusions or alternative recommendations.
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 provided, the description carries the full burden of disclosing behavioral traits. It mentions 'fetch or generate', hinting at possible on-the-fly generation, but does not disclose whether this is a read-only operation, potential side effects, authentication requirements, or rate limits. This is insufficient for an agent to understand safety and side effects.
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, tightly-worded sentence that front-loads the primary action and resource. Every word earns its place, with no filler or redundancy.
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?
Given the lack of annotations, output schema, and parameter explanations, the description is under-specified. The oneOf logic and five parameters are not addressed, and there is no mention of return format or behavior. The tool likely needs more context to be used correctly.
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?
The schema has zero description coverage for all 5 parameters, so the description must compensate. However, it only vaguely says 'for an ad or ad creative' and does not explain the oneOf requirement among ad_id, ad_creative_id, or creative. It adds minimal meaning beyond the schema structure.
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: fetching or generating a rendered preview for an ad or ad creative. This distinguishes it from sibling tools like get_ad and get_ad_creative, which return the underlying objects rather than a visual preview.
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 on when to use this tool over alternatives. There is no mention of prerequisites, exclusions, or scenarios where get_ad or get_ad_creative would be more appropriate. The description simply states what it does without contextual direction.
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 the full burden of behavioral disclosure. It only restates that this fetches a single campaign, providing no information about return format, permissions, error behavior, or the effect of the optional 'fields' parameter. This is minimal and insufficient for a tool with no other safety clues.
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, direct sentence with no filler. It efficiently states the core action and scope, earning every word.
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 tool with no output schema and no annotations, the description is too sparse. It does not explain what the response contains, how the 'fields' parameter influences the result, or any edge cases. Given the simplicity of the task, a more complete description should cover these aspects.
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 only mentions 'by id', giving meaning to the required 'id' but leaving the optional 'fields' array completely unexplained. The schema provides types but no descriptions, so the description fails to compensate for the lack of parameter documentation.
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 specifies the verb 'Fetch', the resource 'campaign', and the scope 'by id', which unambiguously distinguishes it from list_campaigns and other getter tools. It leaves no doubt about 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the contrast with list_campaigns is implicit, the description does not explicitly state when to prefer this over a list operation or mention any preconditions.
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 the full burden of behavioral disclosure. It only states the action and scope, providing no information about pagination, filtering, required permissions, or return format. The verb 'List' implies read-only, but the tool's behavior is not disclosed beyond that.
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 sentence of 7 words, perfectly concise and front-loaded. Every word earns its place, with no filler or repetition of the tool name.
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?
Given 5 parameters, no annotations, and no output schema, the description is far too minimal. It does not address pagination, filtering, required fields, or expected response structure, leaving substantial gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters and description coverage is 0%. The description does not mention any parameter, such as ad_account_id, limit, after, fields, or effective_status, leaving all semantics to the schema alone. This is a significant gap for a tool with multiple parameters.
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 ('List') and resource ('ad images') with a clear scope ('for an ad account'). It clearly distinguishes itself from sibling tools like list_ads (ad images vs. ads) and get_ad_image (plural list vs. singular get).
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 'for an ad account' provides clear context on when to use this tool. However, it does not explicitly mention alternatives or exclusion scenarios, such as 'use get_ad_image for a single ad image' or 'use list_ad_creatives for creative assets.'
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 provided, the description carries the full burden of behavioral disclosure. The verb 'Fetch' indicates a read-only operation, but the description does not disclose error behavior, return format, or permissions. For a simple get-by-id tool this is minimal but adequate.
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 sentence of seven words, front-loaded with the action and resource. Every word is meaningful and there is no redundant information.
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 is low complexity, but the description fails to explain the 'fields' parameter and provides no usage context or return expectations. It covers the core action but leaves meaningful gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes two parameters ('id' and 'fields') with 0% description coverage. The description only mentions 'by id', which adds no semantic detail beyond the schema's property name, and it completely ignores the 'fields' parameter, leaving its purpose ambiguous.
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 'Fetch' and clearly identifies the resource as 'a single ad account' with lookup by 'id'. This distinguishes it from sibling tools like 'list_ad_accounts' (which fetches many) and 'get_campaign' (which fetches a different resource).
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?
No explicit guidance is given about when to use this tool versus alternatives like 'list_ad_accounts'. However, the phrasing 'by id' implies it is for retrieving one specific ad account, and the existence of an obvious list sibling provides implicit context.
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. It only restates the core action ('fetch') without disclosing response format, error behavior, or the effect of the optional 'fields' parameter. This is too minimal to be behaviorally transparent.
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, front-loaded sentence with no filler. Every word adds value.
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?
Given the tool has two parameters and no output schema, the description is too brief. It fails to explain the 'fields' parameter or any return/error behavior, leaving the agent with incomplete information for correct invocation and interpretation.
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?
The phrase 'by id' explains the purpose of the required 'id' parameter. However, the optional 'fields' parameter is not mentioned in the description, and the schema has no parameter descriptions (0% coverage), so the description only partially compensates.
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 'Fetch a single ad set by id', using a specific verb and resource. It distinguishes itself from list_adsets (which lists many) and from get_ad/get_campaign (different resource types).
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: use this when you need a single ad set by its ID. However, it does not explicitly mention alternatives or exclusions, though sibling tool names make the context reasonably clear.
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 must convey behavioral traits. 'Fetch' implies a read-only operation, but there is no mention of pagination, required parameters beyond level, default behavior, or what the response contains. The single sentence does not meaningfully disclose behavior beyond the action itself.
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, front-loaded sentence with no filler or redundancy. It communicates the core purpose efficiently and is appropriately concise for the information it contains.
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?
This is a complex tool with 10 parameters, no schema descriptions, no annotations, and no output schema. The description only covers the core level parameter and purpose. It omits crucial context like default values, parameter interactions, or expected output, making it only partially adequate for such a complex tool.
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?
The description maps the 'level' parameter by naming the four allowed values, but the other nine parameters (limit, fields, breakdowns, entity_ids, time_range, date_preset, ad_account_id, time_increment, action_breakdowns) receive no explanation. Since schema coverage is 0%, the description fails to compensate for the majority of parameters.
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 action (Fetch), the resource (insights), and the scope (account, campaign, ad set, or ad). It distinguishes from sibling tools like get_campaign or list_ads, which fetch entities rather than insights.
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 gives clear context that this tool is for fetching insights across different entity levels, implying it's the right choice when metrics are needed. It doesn't explicitly exclude alternatives or mention sibling tools, but the context is unambiguous.
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. 'Fetch' implies a read-only operation, but the description does not disclose details about return format, pagination, errors, or any potential side effects. It provides basic transparency but lacks depth beyond the action itself.
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 sentence, front-loaded with the verb and resource, and contains no filler. It is appropriately concise for a simple get-by-id tool.
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 description is minimal and covers the core purpose but lacks information about optional parameters, return value, or constraints. Given the presence of a sibling 'list_ad_creatives' and an undocumented 'fields' parameter, more context would be beneficial. Still, for a straightforward get, it is almost viable.
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%, so the description must compensate. It adds meaning for 'id' by indicating lookup by identifier, but completely fails to explain the 'fields' parameter. The schema only provides type/pattern, leaving the semantics of fields undocumented.
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 'Fetch' and identifies the resource 'ad creative' with the scope 'single... by id' clearly. This distinguishes it from sibling tools like list_ad_creatives and get_ad.
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 for retrieving a specific ad creative by ID, but does not explicitly state when to use this vs. list_ad_creatives or mention any alternatives. The context is somewhat clear from the wording but lacks explicit guidance.
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:

[![flin-meta-ads-mcp MCP server](https://glama.ai/mcp/servers/flin-agency/flin-meta-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/flin-agency/flin-meta-ads-mcp)

Score Badge

Copy to your README.md:

[![flin-meta-ads-mcp MCP server](https://glama.ai/mcp/servers/flin-agency/flin-meta-ads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/flin-agency/flin-meta-ads-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/flin-agency/flin-meta-ads-mcp'

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