Social Broadcast MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The tool purposes are mostly distinct: platform listing, account listing, platform connection, refresh, and publishing are separate workflows. The only mild overlap is between list_accounts and refresh_accounts, but their descriptions make the difference understandable.
Naming Consistency4/5
All tool names are in snake_case and follow a verb_noun pattern, which is consistent. Minor deviation is that connect_meta and connect_youtube use platform/brand fragments rather than the generic verb_noun style, but the overall pattern remains clear.
Tool Count5/5
Six tools is well-scoped for a social broadcast server focused on connecting platforms and publishing posts. Every tool covers a meaningful action without unnecessary redundancy.
Completeness4/5
The core lifecycle is mostly covered: list platforms, connect accounts, list/refresh accounts, and publish or schedule posts. Missing disconnect functionality and scheduled-post management are noticeable gaps, but they do not block the primary broadcasting workflow.
Average 3.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción comunica que se trata de un flujo OAuth y que requiere credenciales de Google Cloud, lo cual es contexto de comportamiento relevante. Sin embargo, no se dice qué devuelve la herramienta ni se describe el flujo posterior (URL de autorización, interacción del usuario, finalización), y no hay annotations que compensen.
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?
Es concisa: dos oraciones, con la acción al frente y el requisito principal inmediatamente después. No incluye relleno ni información redundante.
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?
Una herramienta con un flujo OAuth debería indicar qué ocurre después de invocarla, pero la descripción solo menciona 'inicia el flujo' y sus credenciales. No hay output schema, así que la descripción debería compensar esa falta, explicando por ejemplo si devuelve una URL de autorización o un estado.
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?
El schema ya documenta clientId y clientSecret; la descripción agrega la procedencia ('tu proyecto en Google Cloud Console'). El parámetro 'scopes' no tiene descripción en el schema y la descripción no aporta ninguna orientación sobre él, dejando un vacío en la cobertura semántica.
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?
La descripción usa un verbo claro ('Inicia el flujo OAuth') y un recurso específico ('conectar YouTube'), por lo que se entiende bien qué hace la herramienta. No diferencia explícitamente de conect_meta o refresh_accounts, pero el nombre de la plataforma YouTube lo distingue parcialmente de los hermanos.
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 se indica cuándo usar esta herramienta frente a alternativas como refresh_accounts o connect_meta. Se menciona únicamente el requisito de credenciales, pero no hay criterios para elegir entre herramientas ni advertencias de uso.
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. It does disclose the essential behavior: publishing or scheduling a post on a connected account, and it implies side effects such as content becoming visible. It does not mention irreversibility, rate limits, or what happens for invalid/expired accounts, but the core behavior is not hidden.
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 short and has no filler sentences, which is good for efficiency. However, the phrasing 'Publica el programa un post' appears malformed and may confuse an agent despite the short length, so it cannot be considered a polished, high-quality description.
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 schema gives strong parameter coverage and references list_accounts for accountId, which helps. But there is no output schema, no annotations, and the description does not address the workflow around connected accounts, scheduling, or platform-specific options. It is adequate for a straightforward call but leaves gaps for more complex use cases.
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 schema covers 100% of parameters, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema provides, but that is acceptable because the schema already documents content, accountId, mediaUrls, scheduledAt, and platformOptions adequately.
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 identifies the core action: publishing/scheduling a post on a connected account, using a specific verb and resource. It is distinguishable from the sibling tools, which handle listing, connecting, and refreshing accounts, although the wording 'Publica el programa un post' has a grammatical issue that slightly muddies the intent.
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 phrase 'en una cuenta conectada' implies the tool should only be used after an account is connected, which gives some contextual guidance. However, it does not explicitly mention when to use this over alternatives, nor does it point to prerequisites like list_accounts for obtaining the correct accountId.
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 disclosing behavioral traits. It only states that it refreshes an account list, without saying whether it overwrites local data, requires a valid token, performs a network call, or is safe to invoke repeatedly. This is a noticeable gap for a tool that likely synchronizes external account 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence with no filler or redundant information. Every word earns its place, and the important verb and resource appear at the start.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one parameter, no output schema, no annotations—the description covers the core purpose and precondition. However, it leaves unspecified the actual effect on existing account data and does not clarify how this differs from 'list_accounts' in practice, so completeness is adequate but not rich.
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?
There is only one parameter, 'platform', and it has an enum that constrains valid values. Schema description coverage is 0%, but the description adds the key semantic that the platform must already be connected. This is minimally sufficient, though it does not explain each enum value semantically beyond their literal names.
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 ('refresca') and a clear resource ('la lista de cuentas'), and it adds a platform-scoping condition ('ya conectada'). It does not explicitly contrast itself with the sibling 'list_accounts', which could be confused with listing versus refreshing, so it falls just short of a perfect score.
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 phrase 'ya conectada' implies the tool should be used only after a connection has already been established, which gives some usage context. However, it does not mention alternatives, such as when to use 'list_accounts' instead, nor does it state any exclusion criteria.
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 present, so the description carries the burden of behavioral disclosure. 'Lista' implies a read-only operation, but the description does not mention that the `platform` parameter filters results, nor any authentication/refresh behavior. It adds minimal behavioral context beyond the literal meaning.
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 is appropriately concise for its simplicity.
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 simple, but the description is complete only at a high level. It lacks parameter filtering details, return expectations (no output schema), and explicit alternative routing, leaving a partially adequate but not fully self-sufficient description.
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 does not mention the optional `platform` parameter at all, and the schema provides no parameter descriptions (0% coverage). The enum values improve clarity, but the tool description itself fails to explain that the list can be filtered by platform.
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 states a specific verb ('Lista') and resource ('cuentas de redes sociales conectadas'), clearly indicating it returns connected social media accounts. It also places a scope—'conectadas'—which helps distinguish it from list_platforms and connect_* 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus the sibling tools such as list_platforms, connect_meta, or refresh_accounts. An agent must infer the intended use from the tool name and the minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose an important, non-obvious action: 'Abre el navegador para autorizar', indicating an interactive flow. However, it does not explain what happens after authorization (success/failure, token storage, output, or side effects), so transparency is partial.
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?
Three short sentences with no redundant details: purpose, prerequisites, and behavior. The most important information is front-loaded and every sentence earns its place.
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 adequate for selecting the tool, but because there is neither an output schema nor annotations, it leaves unclear what the tool returns and how the agent can tell the OAuth flow succeeded after opening the browser. This is a noticeable gap for an OAuth operation.
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 input schema already documents 100% of the parameters, including default scopes and the exact meaning of clientId/clientSecret. The description adds no significant semantic value beyond repeating that clientId is required and clientSecret is optional.
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?
Starts with a specific verb and resource: 'Inicia el flujo OAuth para conectar Facebook e Instagram'. This clearly separates the tool from siblings such as connect_youtube, and the platform scope is explicit.
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?
States the purpose of the tool and the main prerequisite: need a Facebook app with clientId and optional clientSecret. It does not explicitly exclude alternatives like connect_youtube or mention when not to use the tool, but the platform distinction is clear.
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 hay anotaciones, por lo que la descripción asume toda la carga. 'Lista' implica una operación de solo lectura sin efectos secundarios, pero no se declara explícitamente ni se detalla el formato o alcance de la respuesta. Es suficiente para una herramienta lista muy simple, pero no aporta transparencia rica.
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?
La descripción es una sola oración completa y sin relleno. Cada palabra aporta información sobre el resultado que el agente obtendrá al llamar a la herramienta.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para una herramienta de listado sin parámetros y sin esquema de salida, la descripción es suficientemente completa: indica qué recursos devuelve (plataformas soportadas y sus capacidades). No hay prerrequisitos ni configuraciones adicionales que deban documentarse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La herramienta no tiene parámetros, por lo que aplica el punto de referencia 4. La descripción no necesita explicar semántica de parámetros y el esquema vacío ya comunica que la invocación requiere argumentos.
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?
La descripción identifica un verbo específico ('Lista') y el recurso ('las plataformas soportadas'), además del alcance ('sus capacidades'). Distingue claramente esta herramienta de la hermana list_accounts, que opera sobre cuentas y no sobre plataformas.
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?
El contexto de uso está implícito: llamar a esta herramienta para obtener plataformas y capacidades. Sin embargo, no se mencionan alternativas ni condiciones de exclusión, como en qué casos convendría usar list_accounts o refresh_accounts.
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:

[![social-broadcast-mcp MCP server](https://glama.ai/mcp/servers/diegolm2012-creator/social-broadcast-mcp/badges/card.svg)](https://glama.ai/mcp/servers/diegolm2012-creator/social-broadcast-mcp)

Score Badge

Copy to your README.md:

[![social-broadcast-mcp MCP server](https://glama.ai/mcp/servers/diegolm2012-creator/social-broadcast-mcp/badges/score.svg)](https://glama.ai/mcp/servers/diegolm2012-creator/social-broadcast-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/diegolm2012-creator/social-broadcast-mcp'

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