Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AuditSocials Glossary MCP — 212 терминов рекламы и политик платформ для ИИ

npm version npm downloads license: CC BY 4.0 DOI MCP

Сервер Model Context Protocol (MCP), предоставляющий AI-ассистентам авторитетный глоссарий терминов рекламы в социальных сетях и политик платформ с открытой лицензией — 212 терминов (CC BY 4.0), охватывающих политику платформ, правовые и нормативные рамки (DSA, GDPR, FTC), метрики рекламных технологий, стандарты контента и креативов, конфиденциальность и данные, отраслевые правила, а также правоприменение и риски.

Позвольте AI-ассистентам точно определять и искать термины соблюдения рекламных норм с указанием источника и постоянным URI в каждом ответе — вместо выдумывания определений для регуляторного и платформенного жаргона.

  • 📚 212 тщательно отобранных терминов по 8 категориям — политика платформ, правовые/регуляторные, рекламные технологии, стандарты контента, конфиденциальность, отраслевые правила, правоприменение и риски.

  • 🔗 Цитируемые и постоянные — каждое определение содержит URL источника и стабильный URI w3id.org; набор данных имеет DOI Zenodo.

  • 🆓 Без API-ключа, без настройки — глоссарий встроен и доступен только для чтения; просто npx.

  • 🤖 Основа для RAG и агентов — уменьшение галлюцинаций по терминологии DSA/GDPR/FTC и политик платформ.

Область применения: только глоссарий. Трекер политик AuditSocials, аналитика правоприменения и сканер не предоставляются через этот сервер. Для оперативных проверок политик перед публикацией см. сопутствующий AuditSocials Compliance MCP.

Инструменты

Инструмент

Описание

glossary_define

Определяет термин по имени или slug. Возвращает полное определение, категорию, применимые платформы, связанные термины и постоянный URI.

glossary_search

Поиск по ключевому слову и/или категории. Возвращает соответствующие термины с краткими определениями.

glossary_list_categories

Список категорий глоссария с количеством терминов.

Related MCP server: ProductBrain

Быстрый старт

npx -y auditsocials-mcp

Не требуется ни API-ключ, ни настройка — глоссарий из 212 терминов встроен.

Настройка клиента

Общается по MCP через stdio, поэтому работает с любым MCP-совместимым клиентом.

Claude Desktop / Claude Code — добавьте в mcpServers:

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

Cursor, VS Code, Windsurf, Cline, Continue, Zed и другие MCP-клиенты — укажите им команду npx -y auditsocials-mcp (переменные окружения не нужны).

Использование — просто спросите своего ассистента

  • "Определите блокировку аккаунта, используя глоссарий AuditSocials."

  • "Найдите в глоссарии AuditSocials термины DSA."

  • "Какие категории есть в глоссарии соблюдения рекламных норм AuditSocials?"

  • "Определите теневой бан и перечислите связанные термины."

Каждый ответ включает определение, категорию, применимые платформы, связанные термины, URL источника и постоянный URI — чтобы ваш ассистент цитировал, а не угадывал.

Что внутри

212 терминов, охватывающих:

  • Политика платформ — концепции рекламы и правил сообщества на Meta, TikTok, LinkedIn, Google Ads, YouTube, X, Snapchat, Pinterest.

  • Правовые и регуляторные — DSA, GDPR, FTC, COPPA и связанные рамки.

  • Рекламные технологии и метрики — терминология доставки, атрибуции и измерения.

  • Стандарты контента и креативов, конфиденциальность и данные, отраслевые правила и правоприменение и риски (блокировки, апелляции, демонетизация, теневое ограничение).

Данные, происхождение и лицензия

Курируется AuditSocials — сервисом аналитики политик платформ, который отслеживает изменения политик, действия регуляторов и решения о правоприменении на восьми социальных платформах.

Часто задаваемые вопросы

Что такое AuditSocials Glossary MCP? Сервер MCP, позволяющий AI-ассистентам определять и искать 212 терминов рекламы в социальных сетях и политик платформ с открытой лицензией, с указанием источника в каждом ответе.

Нужен ли мне API-ключ? Нет. Глоссарий встроен и доступен только для чтения — просто запустите npx -y auditsocials-mcp.

Зачем использовать его вместо прямого запроса к модели? Регуляторная терминология и терминология политик платформ (DSA, GDPR, FTC, демонетизация, теневые баны) легко может быть неверно истолкована. Это решение обосновывает ответы на курируемом, цитируемом наборе данных с постоянными URI — идеально для RAG и агентов.

Могу ли я использовать определения в своем продукте? Да, по лицензии CC BY 4.0 с указанием авторства AuditSocials (ссылка на URL источника или DOI).

Какие MCP-клиенты работают? Любой stdio MCP-клиент — Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Continue, Zed и другие.

Ссылки

Разработка

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

Keywords: MCP server, Model Context Protocol, advertising compliance glossary, platform policy terminology, DSA glossary, GDPR terms, FTC advertising, social media policy definitions, content moderation glossary, regtech, ad‑tech glossary, CC BY 4.0 dataset, RAG grounding, AI definitions.

Лицензия

Содержимое: 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