Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AuditSocials Glossary MCP — AIのための212の広告・プラットフォームポリシー用語

npm version npm downloads license: CC BY 4.0 DOI MCP

AIアシスタントに、ソーシャルメディア広告およびプラットフォームポリシー用語の信頼できるオープンライセンスの用語集（212用語、CC BY 4.0）を提供するModel Context Protocol (MCP)サーバー。 プラットフォームポリシー、法規制フレームワーク（DSA、GDPR、FTC）、アドテク指標、コンテンツ・クリエイティブ基準、プライバシーとデータ、業界固有ルール、執行とリスクをカバー。

AIアシスタントに、広告コンプライアンス用語を正確に定義・検索させ、各応答に出典と永続的なURIを付与 — 規制やプラットフォームポリシーの専門用語を幻覚（ハルシネーション）する代わりに。

  • 📚 8カテゴリにわたる212の厳選用語 — プラットフォームポリシー、法規制、アドテク、コンテンツ基準、プライバシー、業界ルール、執行・リスク。

  • 🔗 引用付きで永続的 — 各定義に出典URLと安定したw3id.org URIを付与。データセットにはZenodoのDOIがあります。

  • 🆓 APIキー不要、設定不要 — 用語集はバンドルされ読み取り専用。npxだけでOK。

  • 🤖 RAGとエージェントのグラウンディング — DSA/GDPR/FTCやプラットフォームポリシー用語の幻覚を低減。

対象範囲: 用語集のみ。AuditSocialsのポリシートラッカー、執行インテリジェンス、スキャナーはこのサーバーでは公開されていません。公開前のライブポリシーチェックについては、姉妹品のAuditSocials Compliance MCPをご覧ください。

ツール

ツール

説明

glossary_define

用語名またはスラッグで定義を取得。完全な定義、カテゴリ、該当プラットフォーム、関連用語、永続的なURIを返します。

glossary_search

キーワードおよび/またはカテゴリで検索。一致する用語と短い定義を返します。

glossary_list_categories

用語集のカテゴリと用語数を一覧表示します。

Related MCP server: ProductBrain

クイックスタート

npx -y auditsocials-mcp

APIキーも設定も不要 — 212用語の用語集がバンドルされています。

クライアント設定

stdio経由でMCPを話すため、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は8つのソーシャルプラットフォームにおけるポリシー変更、規制当局の措置、執行決定を監視するプラットフォームポリシーインテリジェンスサービスです。

FAQ

AuditSocials Glossary MCPとは何ですか？ AIアシスタントが212のオープンライセンスのソーシャルメディア広告・プラットフォームポリシー用語を定義・検索でき、各応答に出典を付与するMCPサーバーです。

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/

キーワード: MCPサーバー、Model Context Protocol、広告コンプライアンス用語集、プラットフォームポリシー用語、DSA用語集、GDPR用語、FTC広告、ソーシャルメディアポリシー定義、コンテンツモデレーション用語集、RegTech、アドテク用語集、CC BY 4.0データセット、RAGグラウンディング、AI定義。

ライセンス

コンテンツ: 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