Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AuditSocials Glossary MCP — 212 términos de publicidad y políticas de plataforma para IA

versión de npm descargas de npm licencia: CC BY 4.0 DOI MCP

Un servidor Model Context Protocol (MCP) que proporciona a los asistentes de IA un glosario autorizado y con licencia abierta de terminología de publicidad en redes sociales y políticas de plataforma — 212 términos (CC BY 4.0) que cubren políticas de plataforma, marcos legales y regulatorios (DSA, GDPR, FTC), métricas de ad‑tech, estándares de contenido y creativos, privacidad y datos, reglas específicas de la industria, y cumplimiento y riesgo.

Permite que los asistentes de IA definan y busquen términos de cumplimiento publicitario con precisión, con atribución de fuente y un URI persistente en cada respuesta — en lugar de alucinar definiciones para jerga regulatoria y de políticas de plataforma.

  • 📚 212 términos seleccionados en 8 categorías — políticas de plataforma, legal/regulatorio, ad‑tech, estándares de contenido, privacidad, reglas de la industria, cumplimiento y riesgo.

  • 🔗 Citados y persistentes — cada definición incluye una URL de origen y un URI estable w3id.org; el conjunto de datos tiene un DOI de Zenodo.

  • 🆓 Sin clave API, sin configuración — el glosario está incluido y es de solo lectura; solo npx.

  • 🤖 Fundamento para RAG y agentes — reduce la alucinación en terminología de DSA/GDPR/FTC y políticas de plataforma.

Alcance: solo glosario. El rastreador de políticas, la inteligencia de cumplimiento y el escáner de AuditSocials no están expuestos a través de este servidor. Para comprobaciones de políticas en vivo antes de publicar, consulte el complemento AuditSocials Compliance MCP.

Herramientas

Herramienta

Descripción

glossary_define

Define un término por nombre o slug. Devuelve la definición completa, categoría, plataformas aplicables, términos relacionados y URI persistente.

glossary_search

Busca por palabra clave y/o categoría. Devuelve términos coincidentes con definiciones breves.

glossary_list_categories

Enumera las categorías del glosario con el número de términos.

Related MCP server: ProductBrain

Inicio rápido

npx -y auditsocials-mcp

No se requiere clave API ni configuración: el glosario de 212 términos está incluido.

Configuración del cliente

Habla MCP sobre stdio, por lo que funciona con cualquier cliente compatible con MCP.

Claude Desktop / Claude Code — añadir a mcpServers:

{
  "mcpServers": {
    "auditsocials-glossary": {
      "command": "npx",
      "args": ["-y", "auditsocials-mcp"]
    }
  }
}

Cursor, VS Code, Windsurf, Cline, Continue, Zed y otros clientes MCP — apúntelos al comando npx -y auditsocials-mcp (no se necesita entorno).

Uso — solo pregunte a su asistente

  • "Define 'account suspension' usando el glosario de AuditSocials."

  • "Busca en el glosario de AuditSocials términos sobre DSA."

  • "¿Qué categorías hay en el glosario de cumplimiento publicitario de AuditSocials?"

  • "Define 'shadow ban' y enumera términos relacionados."

Cada respuesta incluye la definición, categoría, plataformas aplicables, términos relacionados, una URL de origen y un URI persistente — para que su asistente cite en lugar de adivinar.

Qué incluye

212 términos que abarcan:

  • Políticas de plataforma — conceptos de publicidad y normas comunitarias en Meta, TikTok, LinkedIn, Google Ads, YouTube, X, Snapchat, Pinterest.

  • Legal y regulatorio — DSA, GDPR, FTC, COPPA y marcos relacionados.

  • Ad‑tech y métricas — terminología de entrega, atribución y medición.

  • Estándares de contenido y creativos, privacidad y datos, reglas específicas de la industria, y cumplimiento y riesgo (suspensiones, apelaciones, desmonetización, limitación encubierta).

Datos, procedencia y licencia

Seleccionado por AuditSocials, un servicio de inteligencia de políticas de plataforma que monitorea cambios de políticas, acciones regulatorias y decisiones de cumplimiento en ocho plataformas sociales.

Preguntas frecuentes

¿Qué es AuditSocials Glossary MCP? Un servidor MCP que permite a los asistentes de IA definir y buscar 212 términos de publicidad en redes sociales y políticas de plataforma con licencia abierta, con atribución de fuente en cada respuesta.

¿Necesito una clave API? No. El glosario está incluido y es de solo lectura — solo ejecute npx -y auditsocials-mcp.

¿Por qué usarlo en lugar de preguntar directamente al modelo? La terminología regulatoria y de políticas de plataforma (DSA, GDPR, FTC, desmonetización, shadow bans) es fácil de entender sutilmente mal. Esto fundamenta las respuestas en un conjunto de datos seleccionado y citado con URIs persistentes — ideal para RAG y agentes.

¿Puedo usar las definiciones en mi propio producto? Sí, bajo CC BY 4.0 con atribución a AuditSocials (enlace a la URL de origen o DOI).

¿Qué clientes MCP funcionan? Cualquier cliente MCP stdio — Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Continue, Zed y otros.

Enlaces

Desarrollo

npm install
npm run export-glossary   # regenerate the bundled snapshot from source data
npm run build             # compile to dist/

Palabras clave: servidor MCP, Model Context Protocol, glosario de cumplimiento publicitario, terminología de políticas de plataforma, glosario DSA, términos GDPR, publicidad FTC, definiciones de políticas de redes sociales, glosario de moderación de contenido, regtech, glosario ad‑tech, conjunto de datos CC BY 4.0, fundamento RAG, definiciones de IA.

Licencia

Contenido: CC BY 4.0 · © AuditSocials

Available Tools

3 tools
glossary_defineA

Define a social media advertising / platform-policy compliance term from the AuditSocials Compliance Glossary. Accepts a term name or slug (e.g. 'account suspension' or 'account-suspension'). Returns the full definition, category, applicable platforms, and related terms.

ParametersJSON Schema
NameRequiredDescriptionDefault
termYesThe term name or slug to define

TDQS

A4.3/5.0
Behavior4/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 clearly implies a read-only lookup (returns a definition) with no side effects. The description does not mention errors, auth, or rate limits, but for a simple glossary lookup, the behavioral traits are sufficiently 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 two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every sentence adds value, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single parameter, no output schema, no annotations), the description fully covers the necessary context: what it does, what input it expects with examples, and what the output contains. No important aspect is missing for a glossary lookup tool.

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?

The schema already describes the parameter ('The term name or slug to define') with 100% coverage. The description adds concrete examples ('account suspension' or 'account-suspension'), which aids the agent in formatting input correctly. This improves upon the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Define a term'), specifies the domain ('AuditSocials Compliance Glossary'), and provides examples of input format. It is distinct from sibling tools glossary_search (which likely searches) and glossary_list_categories (which lists categories), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool returns (definition, category, platforms, related terms), which helps an agent decide when to use it. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, leaving the decision partially implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

glossary_list_categoriesA

List the AuditSocials Compliance Glossary categories with the number of terms in each. Useful to understand the scope of the vocabulary.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It correctly indicates a read-only operation (listing with counts) and adds context about grouping by category. The behavior is transparent and appropriate, though no details on potential pagination or output format are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the core action and then explains utility, perfect for quick agent parsing.

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?

Given no parameters, no output schema, and simple sibling context, the description is sufficiently complete. It explains the output (categories with counts) and its usefulness. Minor gap: no mention of sorting or hierarchical structure if applicable.

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?

The tool has zero parameters, so the description need not add parameter details. It compensates by explaining what information is returned (categories with term counts), adding meaning beyond the empty 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 clearly states the tool lists glossary categories with term counts, using specific verbs ('list') and resources ('categories'). It distinguishes itself from siblings like glossary_define and glossary_search by highlighting the purpose of understanding vocabulary scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by noting it's useful for understanding vocabulary scope, but provides no explicit guidance on when to use this versus siblings. It lacks exclusions or context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedglossary_define
    • First observedglossary_list_categories
    • First observedglossary_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct and non-overlapping purpose: define a specific term, search by keyword, and list categories. There is no ambiguity about which tool to use for a given task.

Naming Consistency5/5

All tools follow the consistent pattern 'glossary_<verb>_<noun>' (glossary_define, glossary_search, glossary_list_categories). The naming is predictable and clearly conveys the action and resource.

Tool Count4/5

Three tools is a reasonable number for a focused glossary server. It covers the core operations without being too sparse, though a few more tools (e.g., list all terms) could be added without causing bloat.

Completeness4/5

The tool surface covers the essential workflows: discovering terms (search and categories) and retrieving detailed definitions. A minor gap is the lack of a tool to list all terms directly, but the search and category tools adequately enable discovery.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers