ClaudeMetaMCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct action (post, list, insights, comments, campaign management) on a specific platform (Instagram, Facebook, Meta Ads). No two tools have overlapping purposes; even similar tools like metricas_campania and metricas_breakdown_ads are clearly differentiated by aggregate vs. breakdown.
Naming Consistency5/5All tools use consistent snake_case naming with a verb_noun pattern (publicar_instagram, listar_campanias, crear_ad). Spanish verbs are uniformly applied, and the pattern is predictable across all 20 tools.
Tool Count5/520 tools is well-scoped for a Meta/Instagram/Facebook marketing server. It covers posting, insights, comment management, and full Meta Ads lifecycle (campaigns, ad sets, creatives, ads) without unnecessary bloat or missing essential operations.
Completeness4/5The tool surface covers the main workflows: posting to Instagram (feed and carousel), viewing insights, managing comments, and full Meta Ads campaign management. Minor gap: Instagram Stories are intentionally excluded due to API limitations, but the rest is comprehensive.
Average 3.4/5 across 20 of 20 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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.jsonto 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?
No annotations are provided, so the description must cover behavioral traits. It only states that it lists latest posts, but does not disclose whether the operation is read-only, what data is returned, or any authentication or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but not front-loaded with all critical information. It omits the optional limit parameter, making it incomplete despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single optional parameter, no output schema, and no annotations, the description should provide more context about the response, limits, and usage. It fails to do so, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the sole parameter 'limit'. It does not mention it at all, forcing the agent to rely solely on the schema, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the latest posts from Niveals' Instagram account, using a specific verb ('lista') and resource ('publicaciones'). It distinguishes itself from sibling tools like listar_comentarios_instagram and insights tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as when to get insights or comments instead. It merely states the function without 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only lists example metrics and does not mention that the tool is read-only, what the return format is, any permission requirements, or rate limits. The description lacks transparency about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the purpose. It avoids fluff but could benefit from a brief list or separation of key details without significantly increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about return values, default behavior, and edge cases. It only covers a subset of available metrics and does not explain how period or metricType affect results, leaving the agent underspecified for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are described in the schema. The description adds minimal value by providing examples of the 'metric' parameter (reach, follower_count, profile_views) but does not explain the 'period' or 'metricType' parameters beyond what the schema states. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides organic insights for an Instagram account, listing examples like reach, followers, and profile views. The name and description imply account-level insights, distinguishing it from sibling tools like 'insights_publicacion_instagram' which focus on individual posts, though this differentiation is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when to choose account-level vs. post-level insights. There is no mention of prerequisites, exclusions, or best practices.
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 full burden. It indicates a list operation (read-only, non-destructive), which is implied by 'Lista'. However, it doesn't disclose scope, sorting, or potential empty results. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is front-loaded with the verb. However, it could include brief parameter context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is incomplete as it omits the 'limit' parameter. Agents lack insight into result pagination or size control. With sibling list tools, more context would help differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'limit', has no description in schema (0% coverage). The tool description does not mention it, leaving agents unaware of its purpose (limiting result count). The description adds no value over schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (list) and the resource 'campañas' (campaigns), specifying the account. It is distinguishable from sibling tools like 'crear_campania' as a read operation, though it doesn't explicitly differentiate from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives, such as when a limit is needed or prerequisites like authorization. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as read-only nature, rate limits, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information, well-structured for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description lacks details about response format, pagination, error handling, or other critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only 'mediaId' has a description, but the limit parameter is undocumented in both schema and description. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (listar) and resource (comentarios de una publicación de Instagram), distinguishing it from sibling tools like 'responder_comentario_instagram' and 'listar_publicaciones_instagram'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; limited context 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?
No annotations provided, so the description carries full burden. It adds one behavioral trait (includes scheduled posts) but omits pagination, rate limits, authentication needs, or error handling. Very minimal disclosure beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It is concise, though it could optionally add a brief note about the return type without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is minimally adequate: it states the action and one behavioral detail (scheduled posts). However, it lacks return format, pagination hints, or ordering, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not mention the 'limit' parameter at all. The description adds no meaning beyond the schema, failing 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists posts from a Facebook page, including scheduled ones. It uses a specific verb (list) and resource (posts) and distinguishes from sibling tools like publicar_facebook or instagram-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context about when not to use it. The description only implies usage for listing posts but doesn't help the agent decide between this and similar tools.
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 provided, so the description carries full burden. It mentions operating levels and example breakdowns but lacks disclosure about side effects, authentication, rate limits, or data freshness. Behavior as a read operation is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and scope. It is concise with no wasted words, though the structure could be slightly improved by separating the main function from the operational levels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully describes parameters, the description is minimally complete for a simple metrics tool. However, it lacks details about output format, pagination, or what specific metrics are returned, which limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all three parameters. The description does not add additional semantic context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides ad metrics with breakdowns by age, gender, location, platform, etc., and specifies it works at campaign, ad set, ad, or account level. This differentiates it from siblings like metricas_campania, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., metricas_campania). No context about prerequisites or limitations. The description implies usage for broken-down metrics but provides no explicit 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 must fully disclose behavioral traits. It only states what fields can be edited and that it does not recreate. Missing: partial vs full update, idempotency, error handling (e.g., invalid campaignId), permission requirements, side effects, return value. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and resource. No filler or redundancy. Efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate complexity (5 params, mutation, no output schema), the description is too brief. It does not cover typical expectations for an update operation: success/error responses, validation rules, required permissions, or related actions. The agent lacks essential context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (40%). The description adds meaning by listing the editable fields (nombre, estado, presupuesto) and clarifying that budget values are in centavos. However, it fails to explain the required campaignId parameter (what it identifies) and gives no additional constraints or format hints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Edita') and resource ('campaña existente'), explicitly distinguishes from create ('sin recrearla'), and lists the modifiable fields (nombre, estado, presupuesto). This differentiates it from siblings like crear_campania or pausar_campania.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. For instance, status changes can also be done via pausar_campania or activar_campania, but the description does not clarify when one is preferred. The only implicit distinction is 'sin recrearla', which separates it from creation.
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 reveals one behavioral trait: the ad set is created in PAUSED state. However, with no annotations provided, it fails to disclose other important aspects like whether it requires specific permissions, if it overwrites existing data, rate limits, or what happens if required parameters are omitted. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and immediately conveys the tool's purpose and a key behavioral note (PAUSED). Every word earns its place, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema (15 parameters, 4 required, nested objects) and no output schema, the description is too sparse. It does not explain how the parameters interact, the relationship to the campaign, or how to set budgets and targeting. The note about PAUSED is helpful but incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, so the schema already documents many parameters (e.g., 'endTime', 'countries', 'targeting'). The description adds nothing beyond what is in the schema or the name. Baseline 3 is appropriate since the schema partially compensates, but the description does not clarify semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates an ad set with segmentation, budget, and optimization within a campaign, and explicitly mentions it is initially paused. This distinguishes it from sibling tools like 'crear_ad' (creates an ad within an ad set) and 'crear_campania' (creates a campaign).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention prerequisites, such as requiring a campaign to exist first, or when to use other budget/optimization settings. Sibling tools exist but no differentiation is made.
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 only mentions returned metrics but omits behavioral details like read-only nature, permission requirements, or error handling for invalid campaignId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main purpose. Slightly vague with 'etc.' but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description lacks return format or structure. Still, for a simple metrics retrieval tool with well-documented parameters, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds no new meaning beyond the schema (e.g., 'etc.' is vague). Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns campaign metrics (impressions, clicks, CTR, etc.), distinguishing it from sibling tools like listar_campanias (lists campaigns) and metricas_breakdown_ads (breakdowns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus metricas_breakdown_ads or other campaign tools. No mention of prerequisites or 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 full burden. It states it creates a creative and returns an ID, but does not disclose behavioral traits such as permission requirements, side effects, or whether it modifies existing resources. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core purpose and return value. No fluff, efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does mention the return value. However, given the complexity (7 parameters, no annotations), it lacks details on error conditions, parameter dependencies, or usage nuances. Completeness is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 57% description coverage. The description adds context by linking some parameters (message, link, image) to the tool's function, but does not explain parameters like description or instagramUserId 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a creative (ad content) from a Facebook Page, specifying the components: message, link, image. It returns creative_id. Differentiates from sibling tools like crear_ad which create the whole ad, and other tools that manage campaigns or Instagram posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the source (Página de Facebook) and components, providing some context for when to use. However, it lacks explicit guidance on when to use this tool versus alternatives like crear_ad, or any prerequisites or exclusions.
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 bears full responsibility for behavioral disclosure. It only states that the tool publishes a carousel, without mentioning side effects, authentication needs, rate limits, or potential failures. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of publishing a carousel to Instagram (e.g., authentication, account permissions, image specifications, immediate vs. scheduled posting), the description is far too brief. No output schema exists, so the description should cover more context, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'imageUrls' has a description). The tool description adds no additional meaning for the 'caption' parameter, which lacks any schema description. It merely restates the image count range already present in the schema. More detail on the caption parameter would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Publica' (publish), resource 'carrusel' (carousel) with the specific range of 2 to 10 images, and the target 'feed de Instagram de Niveals'. This distinguishes it from the sibling tool 'publicar_instagram', which presumably posts a single image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for carousel posts with 2-10 images, naturally contrasting with single-image posting. However, it does not explicitly state when to use this tool versus 'publicar_instagram' or other siblings, nor does it provide any exclusions or prerequisites.
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 must carry the full burden. It mentions the type of data returned (reach, saves, interaction) but does not disclose if the operation is read-only, any rate limits, or required permissions. Basic behavioral transparency is present but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose. It is front-loaded and contains no superfluous information, though it could be slightly more detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters) and no output schema, the description provides sufficient context for basic usage, mentioning example metrics. However, it does not specify the full response structure or error conditions, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds general context about returned metrics but does not enumerate valid values for the 'metric' parameter. Since the schema already provides basic descriptions, the additional value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides insights (reach, saves, interaction) for a specific Instagram post. It uses a specific verb+resource combination and distinguishes from siblings like 'insights_cuenta_instagram' (account-level) and 'listar_publicaciones_instagram' (listing posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching metrics of a single post, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or prerequisites, leaving the agent to infer from 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 discloses the scheduling feature and time constraints. However, it does not mention authentication needs, rate limits, or behavior when a link is provided. It lacks completeness on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence immediately states the purpose, and the second adds scheduling details. Every word is informative without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description leaves gaps. It does not mention required permissions, return values (e.g., post ID), or how the link parameter affects the post. For a Facebook API tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%). The description adds meaning to the scheduledPublishTime parameter by specifying the valid time window. It does not elaborate on the message or link parameters, which remain under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Publica en la Página de Facebook de Niveals', specifying the resource and action. It implicitly distinguishes from sibling tools like publicar_instagram and listar_posts_facebook by focusing on Facebook posting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific guideline about scheduling with scheduledPublishTime and its constraints (10 min to 6 months). However, it does not explicitly state when to use this tool versus alternatives, nor does it exclude other scenarios like listing posts.
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 full burden. It barely discloses behavior beyond the basic action; it does not mention authentication, rate limits, idempotency, or side effects like overwriting existing posts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first gives main purpose, second adds a key exclusion. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema, the description is adequate but missing details like return values (e.g., post ID) or error conditions. It could be more helpful with post-creation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter (e.g., 'Usar imageUrl O videoUrl'). The description adds no new parameter specifics but reinforces the mutual exclusivity of imageUrl and videoUrl.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it publishes images or reels to the Instagram feed. It distinguishes itself from siblings like publicar_carrusel_instagram and explicitly excludes Stories, making the tool's specific verb+resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (for feed posts) and explicitly not for Stories. It does not compare with other sibling tools for carousel or insights, but the exclusion is clear and helpful.
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 must carry the full burden. It discloses that the clone includes ad sets and ads and is created in PAUSED state. However, it does not mention the optional 'deepCopy' parameter or its default behavior, nor any limitations or side effects. The description provides basic behavioral context but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the action and scope, the second specifies the resulting state. Every sentence adds value with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description effectively communicates the core operation: cloning a campaign with its ads and setting the copy to paused. It lacks details like the original being unchanged or the copy getting a new ID, but these are minor omissions for a well-understood cloning operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only deepCopy has a description). The tool description does not explicitly describe parameters but implies the meaning of 'campaignId' (the campaign to clone) and suggests deep copy via 'con sus ad sets y ads'. This adds some context beyond the schema but does not fully compensate for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Clona' (clones) and the resource 'campaña existente' (existing campaign), and specifies the scope 'con sus ad sets y ads' (with its ad sets and ads) and the resulting state 'PAUSED'. This distinguishes it from sibling tools like 'crear_campania' which creates from scratch, and 'pausar_campania' which only changes state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use it to clone an existing campaign including its ad sets and ads. It does not provide explicit when-not scenarios or compare to alternatives like 'crear_campania'. The guidance is implied by the tool's purpose, but lacks explicit exclusions.
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 must carry the burden. It discloses that the tool stops spending, but fails to mention reversal, permission requirements, or side effects. For a mutation tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded with the verb and subject, and the parenthetical adds value without increasing length unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately covers the core action. However, it lacks details on immediate effects, response, or prerequisites, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required parameter 'campaignId', which is well-described in the schema as 'ID de la campaña.' The description adds no additional semantic detail beyond what the schema provides, so baseline score 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Pausa' (pauses) and the resource 'una campaña de Meta Ads', with an explanatory parenthetical 'deja de gastar' that clarifies the effect. This distinguishes it from sibling tools like activar_campania (activate) and crear_campania (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for stopping campaign spending but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. The sibling activar_campania offers a contrast, but the description does not mention 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 bears full burden. It discloses that the response is visible and public, which is important. However, it does not mention authentication requirements, rate limits, or whether the action is reversible. The warning adds some transparency but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences (one for purpose, one for warning). Every word is necessary; no fluff. It's well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value or success confirmation. For a simple action tool, it covers the main purpose and a key warning, but is not fully complete without output schema. It does not explain what the agent should expect after execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions in the schema. The tool description adds no additional meaning beyond the schema. According to rules, baseline 3 is appropriate when coverage is high and description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Responde a un comentario de Instagram' with a specific verb and resource. It distinguishes from siblings like 'listar_comentarios_instagram' (listing) and 'publicar_instagram' (new posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning: 'Publica una respuesta visible; confirmá el texto con el usuario.' This guides when to use (with caution and user confirmation). It doesn't explicitly say when not to use, but the sibling 'listar_comentarios_instagram' is implied as an alternative for non-destructive actions.
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 full burden. It discloses two key behaviors: creation of an ad and setting its initial state to PAUSED. However, it does not mention if the tool is idempotent, what happens if the ad set or creative doesn't exist, or any side effects. Still, the essential behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 simple required params, no output schema), the description covers the core purpose and behavior. It lacks details on return values or error conditions, but these are not critical for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context that 'adsetId' and 'creativeId' refer to existing objects to be joined, going beyond the schema. 'name' is not elaborated. With 0% schema description coverage, the description partially compensates but could provide more detail on parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it creates a final ad by joining an ad set with a creative. It distinguishes itself from sibling tools like crear_ad_set and crear_creative by specifying that it combines them. The paused state is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used after creating an ad set and creative, but it does not explicitly state prerequisites or when not to use it. No alternatives are mentioned, so guidance is minimal.
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 must carry the full burden. It discloses the critical behavioral trait that the campaign starts in paused state, which is valuable. However, it does not describe permissions, idempotency, or potential side effects beyond the initial state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no wasted words. The most important information (creation, paused state) is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the essential behavioral context (paused state) and purpose. It does not explain return values or error handling, but those are less critical for a creation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all parameters adequately. The description adds no additional meaning beyond what the schema provides (e.g., default values, constraints, or usage tips). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'crea' (creates) and the resource 'campaña de Meta Ads', specifying exactly what the tool does. It also includes the behavioral note about being created in PAUSED state, which distinguishes it from sibling tools like activar_campania.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance that the campaign is always created paused and must be activated with activar_campania, effectively instructing the user on the next step. However, it does not explicitly mention when to use this tool versus alternatives like actualizar_campania or duplicar_campania.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the critical behavioral impact of budget spending with an emoji warning, which is essential information beyond any annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, followed by a clear warning. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple activation tool with one parameter and no output schema, the description fully covers purpose, risk, and usage advice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'ID de la campaña'; description adds no extra meaning beyond schema, hence baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses an explicit verb ('Activa') and resource ('campaña de Meta Ads'), clearly distinguishing from sibling tools like pausar_campania and crear_campania.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that the tool starts spending budget and instructs the user to confirm before calling, providing direct guidance on when to use it.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Alan7799DE/ClaudeMetaMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server