Skip to main content
Glama
nogu66

Satori Syntax MCP Server

by nogu66
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

さとり構文 MCP

npm version License: MIT

https://github.com/user-attachments/assets/64a88176-9852-4ffa-857e-8d9960f8c107

X（旧Twitter）投稿用の効果的なさとり構文を生成するModel Context Protocol (MCP) サーバーです。140文字以内で読者の心を掴む構文を5つのパターンから選択して生成できます。

主な機能

  • 高速で軽量。構造化されたテンプレートベースの生成で瞬時に構文を作成

  • LLMフレンドリー。MCPプロトコルによる構造化されたデータ操作

  • 決定論的な構文生成。曖昧さを排除した明確なパターンベースのアプローチ

動作要件

  • Node.js 18以降

  • VS Code、Cursor、Windsurf、Claude Desktop、Goose、またはその他のMCPクライアント

さとり構文タイプ

  • A: 基本形 - 万能でどんな状況にも適応可能な構文

  • B: 常識の否定 - 常識や既成概念を覆すことで読者の関心を引きつける

  • C: 一般的なニュース - ニュースを軸にしつつ、読者の興味を引く構文

  • D: 衝撃的なニュース - 驚きや感動を伴う内容で感情を動かす

  • E: ステップ紹介 - 具体的な手順を示して行動を促す構文

はじめに

まず、お使いのクライアントでSatori Syntax MCPサーバーをインストールしてください。

標準設定 ほとんどのツールで動作します：

{
  "mcpServers": {
    "generate-satorify": {
      "command": "npx",
      "args": [
        "@shuhary/satorify-mcp@latest"
      ]
    }
  }
}

Claude Code CLIを使用してSatori Syntax MCPサーバーを追加：

claude mcp add generate-satorify npx @shuhary/satorify-mcp@latest

MCPインストールガイドに従い、上記の標準設定を使用してください。

Cursor Settings → MCP → Add new MCP Serverに移動。お好みの名前を付け、コマンドnpx @shuhary/satorify-mcpでcommandタイプを使用してください。Editをクリックして設定を確認したり、コマンドライン引数を追加することもできます。

Advanced settings → Extensions → Add custom extensionに移動。お好みの名前を付け、タイプSTDIOを使用し、commandをnpx @shuhary/satorify-mcpに設定してください。"Add Extension"をクリックします。

MCPインストールガイドに従い、上記の標準設定を使用してください。VS Code CLIを使用してSatori Syntax MCPサーバーをインストールすることもできます：

# VS Code用
code --add-mcp '{"name":"generate-satorify","command":"npx","args":["@shuhary/satorify-mcp@latest"]}'

インストール後、VS CodeのGitHub Copilotエージェントでサーバーが利用可能になります。

Windsurf MCPドキュメントに従い、上記の標準設定を使用してください。

ツール

  • generate_satori_syntax

    • タイトル: さとり構文生成

    • 説明: 指定されたパラメータに基づいて140文字以内のさとり構文を生成

    • パラメータ:

      • structure_type (string, 必須): 構文タイプ（A/B/C/D/E）

      • target_audience (string, 必須): ターゲット層

      • message_content (string, 必須): 伝えたいメッセージの内容

      • expected_action (string, 必須): 期待する行動

      • news_content (string, オプション): ニュース内容（構文CとDで使用）

    • 読み取り専用: false

  • get_satori_structure_types

    • タイトル: 構文タイプ一覧取得

    • 説明: 利用可能なさとり構文タイプの一覧を取得

    • パラメータ: なし

    • 読み取り専用: true

設定

Satori Syntax MCPサーバーは以下の引数をサポートしています。これらは上記のJSON設定で"args"リストの一部として提供できます：

> npx @shuhary/satorify-mcp@latest --help
  --output-dir <path>          出力ファイル用のディレクトリパス
  --config <path>              設定ファイルのパス
  --help                       ヘルプを表示

設定ファイル

Satori Syntax MCPサーバーはJSON設定ファイルを使用して設定できます。--configコマンドラインオプションを使用して設定ファイルを指定できます：

npx @shuhary/satorify-mcp@latest --config path/to/config.json
{
  // 出力ファイル用のディレクトリ
  outputDir?: string;

  // さとり構文生成の設定
  generation?: {
    // デフォルトの文字数制限（デフォルト: 140）
    maxLength?: number;
    
    // デフォルトの構文タイプ
    defaultStructureType?: 'A' | 'B' | 'C' | 'D' | 'E';
  };
}

Related MCP server: X(Twitter) MCP Server

開発

ソースからビルド

git clone https://github.com/nogu66/satorify-mcp.git
cd satorify-mcp
npm install
npm run build

開発環境のセットアップ

npm install
npm run dev  # ウォッチモードでの開発

テスト実行

npm test

ディレクトリ構造

src/
├── index.ts              # MCPサーバーのメインファイル
├── types.ts              # 型定義
└── satori-templates.ts   # さとり構文テンプレート

貢献

プルリクエストやイシューの報告を歓迎します。

ライセンス

MIT License

注意事項

  • このツールはさとり構文のプロンプトを生成します。実際の構文生成にはLLMが必要です。

  • さとり構文生成は、使用しているLLM（Claude、ChatGPT、Geminiなど）で実行してください。

  • さとり構文の使用には十分注意し、適切なターゲットと内容で使用してください。

  • X（Twitter）の利用規約に従って使用してください。

  • 生成されたコンテンツの品質や適切性についてご自身で確認してください。 `

サポート

問題が発生した場合は、GitHubのイシューで報告してください。

Available Tools

2 tools
generate_satori_syntaxC

さとり構文を生成します（140文字のX投稿用）

ParametersJSON Schema
NameRequiredDescriptionDefault
structure_typeYes構文タイプ（A: 基本形、B: 常識の否定、C: 一般的なニュース、D: 衝撃的なニュース、E: ステップ紹介）
target_audienceYesターゲット層（例: 副業を始めたい人、AIに興味がある人）
message_contentYes伝えたいメッセージの内容
expected_actionYes期待する行動（例: サービスを試す、投稿をシェアする）
news_contentNoニュース内容（構文CとDで使用、オプション）

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It mentions generating syntax for 140-character X posts, which implies a creation operation, but doesn't cover aspects like whether this is a read-only or mutative action, any rate limits, authentication needs, or what the output format looks like (e.g., text string). This is a significant gap for a tool with no annotation coverage.

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, efficient sentence in Japanese that directly states the tool's purpose and constraint (140 characters). It is front-loaded with no unnecessary words, making it highly concise and well-structured for quick understanding.

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

Completeness2/5

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

Given the complexity of a generation tool with 5 parameters and no annotations or output schema, the description is incomplete. It doesn't explain the output (e.g., what the generated syntax looks like), behavioral traits like mutability or side effects, or usage context. This leaves gaps that could hinder an AI agent in correctly invoking the tool.

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 description coverage is 100%, with detailed descriptions for all parameters, including an enum for 'structure_type' with clear mappings. The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage tips. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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 clearly states the tool's purpose: 'generate Satori syntax (for 140-character X posts).' It specifies the verb ('generate') and resource ('Satori syntax'), and includes the constraint of 140 characters. However, it doesn't differentiate from its sibling tool 'get_satori_structure_types,' which likely provides structure types rather than generating syntax, so it misses full sibling distinction.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool or any other context for usage, such as prerequisites or scenarios where this tool is preferred over others. This leaves the agent with no explicit or implied usage instructions.

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

get_satori_structure_typesB

さとり構文の利用可能な構文タイプ一覧を取得します

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/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 of behavioral disclosure. It states the tool retrieves a list but doesn't describe any behavioral traits such as whether it's read-only, if it requires authentication, rate limits, error handling, or what the return format looks like (e.g., JSON array, plain text). This leaves significant gaps for an agent to understand how to invoke it correctly.

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, efficient sentence in Japanese that directly states the purpose without any wasted words. It's appropriately sized for a simple tool with no parameters, and the information is front-loaded with the core action and resource.

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

Completeness2/5

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

Given the tool has no annotations, no output schema, and 0 parameters, the description is minimal. While it states the purpose clearly, it lacks essential contextual details for a tool that retrieves data: no information on return format, error conditions, or behavioral constraints. For a retrieval tool, this leaves the agent with insufficient guidance on what to expect from the invocation.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which is correct for a parameterless tool. It adds value by specifying what is being retrieved (syntax types for Satori syntax), which goes beyond the empty schema.

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 clearly states the action ('取得します' - get/retrieve) and the resource ('さとり構文の利用可能な構文タイプ一覧' - list of available syntax types for Satori syntax). It distinguishes from the sibling tool 'generate_satori_syntax' by focusing on listing types rather than generating syntax. However, it doesn't specify the format or scope of the list (e.g., all types, filtered, paginated).

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 explicit guidance on when to use this tool versus alternatives is provided. The description implies this is for retrieving available syntax types, but there's no mention of prerequisites, when not to use it, or how it relates to the sibling 'generate_satori_syntax' tool. Usage is implied from the purpose alone.

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. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedgenerate_satori_syntax
    • First observedget_satori_structure_types
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one generates content (generate_satori_syntax) and the other retrieves metadata about available structure types (get_satori_structure_types). There is no overlap in functionality, making it impossible for an agent to confuse them.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (generate_satori_syntax, get_satori_structure_types) with clear, descriptive verbs that match their actions. The naming is uniform and predictable across the set.

Tool Count2/5

With only 2 tools, the server feels thin for its purpose of generating and managing Satori syntax. A typical syntax generation server might include additional tools for validation, customization, or history management, making this set borderline minimal.

Completeness3/5

The server covers core generation and type listing, but there are notable gaps. For example, no tools exist for validating syntax, editing generated content, or managing user preferences, which could limit agent workflows in this domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • X(Twitter) MCP Server

    cjkcr
    A
    license
    B
    quality
    D
    maintenance
    Enables creating, managing, and publishing X/Twitter posts, threads, and replies directly through Claude chat. Supports draft management with the ability to create, list, publish, and delete tweet drafts.
    10
    1
    MIT

  • LinkedIn Content Creation MCP

    IBM
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables creation of optimized LinkedIn posts using a component-based design system with variants, themes, and composition patterns. Supports multiple post types (text, document, poll, video, carousel) with research-backed optimization for maximum engagement.
    3
    Apache 2.0

Latest Blog Posts

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/nogu66/satorify-mcp'

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