dialpad-automation

dialpad-automation skill の概要

dialpad-automation の用途

dialpad-automation は、Composio の Rube MCP server 経由で Dialpad 操作を実行するための Claude skill です。すでに Dialpad を業務で使っていて、AI エージェントに現在の Dialpad tool schema の確認、認証状態のチェック、対応済みアクションの実行まで任せたいユーザーに向いています。API フィールドを手作業で推測しながら指定する必要を減らせます。

この skill の主目的は、「一般的な Dialpad の使い方を書く」ことではありません。AI アシスタントが Rube MCP を正しく使えるように、まず利用可能な Dialpad tools を検索し、Dialpad 接続を確認し、その時点の schema に合った適切な tool を呼び出すためのものです。

向いているユーザーとワークフロー

Claude Desktop などの MCP 対応クライアント、または https://rube.app/mcp に接続できる別のアシスタント環境から、Dialpad 関連の作業を自動化したい場合にこの skill を使います。

特に相性がよい用途は次のとおりです。

• Composio 経由で現在公開されている Dialpad アクションを確認する
• エージェント経由で、繰り返し使う Dialpad ワークフローを準備または実行する
• 実行前に tool discovery を強制し、schema エラーを減らす
• Dialpad を大きな Workflow Automation の一工程として組み込む、アシスタント主導の業務フローを構築する

dialpad-automation skill は、利用可能な Dialpad tool 名やフィールドが変わる可能性がある環境で特に有用です。古い前提に依存せず、エージェントに RUBE_SEARCH_TOOLS を呼び出すよう指示するためです。

インストール前に確認すべき制約

この skill は Rube MCP と、Composio 内で有効化された Dialpad 接続に依存します。ローカルスクリプト、参照ファイル、補助アセットは含まれておらず、実装は SKILL.md にあります。そのため軽量ですが、うまく使えるかどうかは MCP 設定とプロンプトの明確さに大きく左右されます。

dialpad-automation を、単体で動く Dialpad SDK、CLI ラッパー、または事前構築済みの業務ワークフローとして期待してインストールしないでください。これは Rube MCP 経由で Dialpad tools を発見し、利用するためのエージェント向け指示レイヤーです。

dialpad-automation skill の使い方

dialpad-automation のインストールとセットアップ手順

GitHub skill repository から skill をインストールします。

npx skills add ComposioHQ/awesome-claude-skills --skill dialpad-automation

次に、クライアント側で Rube MCP を設定するため、以下を追加します。

https://rube.app/mcp

Dialpad の作業を依頼する前に、MCP server が RUBE_SEARCH_TOOLS を公開していることを確認してください。そのうえで、dialpad toolkit を指定して RUBE_MANAGE_CONNECTIONS を使います。Dialpad が有効でない場合は、返された認証フローを完了し、接続ステータスが ACTIVE であることを確認します。

リポジトリを確認する場合は、まず次のファイルから見ます。

• composio-skills/dialpad-automation/SKILL.md

現在の skill path には追加の rules/、resources/、references/、scripts/ フォルダはありません。そのため、SKILL.md が信頼すべき唯一の情報源です。

skill に必要な入力

有効な dialpad-automation usage プロンプトには、次の情報を含めるとよいです。

• 実現したい Dialpad 上の結果
• contact、user、call、message、workspace など、既知の識別子や詳細
• エージェントに計画だけさせるのか、情報取得まで行わせるのか、変更実行まで許可するのか
• 「メッセージを送信しない」「レコード変更前に確認する」などの安全制約
• 既存の Rube session を再利用するのか、新規作成するのか

弱いプロンプト:

“Use Dialpad to handle my calls.”

より強いプロンプト:

“Use the dialpad-automation skill. First call RUBE_SEARCH_TOOLS for available Dialpad tools related to retrieving recent call records. Check that the Dialpad connection is active. If a read-only tool exists, fetch the last 10 calls for the authenticated account. Do not create, update, or delete anything.”

後者のほうが結果が安定します。期待するアクション、安全境界、そして skill が前提とする discovery sequence を明示しているためです。

推奨される実行ワークフロー

信頼しやすい dialpad-automation guide は、次の順序で進めます。

1. 具体的な Dialpad のユースケースを指定して、RUBE_SEARCH_TOOLS で tools を検索する。
2. 返された tool slugs、schemas、execution plans、pitfalls を確認する。
3. RUBE_MANAGE_CONNECTIONS で dialpad の接続ステータスを確認する。
4. 有効であれば、目的を discovery 済みの schema に対応づける。
5. 書き込み操作の前に確認を求める。
6. 選択した tool を実行し、結果を要約する。

複数ステップのワークフローでは、Rube session ID を一貫して使うと、エージェントが discovery から execution までの文脈を保ちやすくなります。

実用的なプロンプトパターン

制御された実行をしたい場合は、次のようなプロンプトを使います。

“Use dialpad-automation for Workflow Automation. Search Rube tools first for: [specific Dialpad task]. Use the returned schemas only. Check the dialpad connection. If the task requires a write action, show me the planned tool call and wait for approval. If it is read-only, execute it and summarize the key fields returned.”

このパターンは、skill の中核となる指示と合っています。つまり、Dialpad schemas を推測せず、必ず実行時に発見するという考え方です。

dialpad-automation skill FAQ

dialpad-automation は Rube MCP なしでも使えますか？

いいえ。この skill には Rube MCP が必要です。特に RUBE_SEARCH_TOOLS と RUBE_MANAGE_CONNECTIONS へのアクセスが前提です。MCP アクセスと有効な Dialpad 接続がなければ、Dialpad automation は実行できません。

通常の Dialpad プロンプトより何が優れていますか？

通常のプロンプトでは、API endpoints、tool names、fields を幻覚的に作り出してしまう可能性があります。dialpad-automation は、アクションの前に Rube MCP 経由で Composio の現在の Dialpad toolkit を検索するようアシスタントに指示します。そのため、特に schema や対応アクションが変わる可能性のある live tool use に向いています。

初心者にも使いやすい skill ですか？

MCP クライアントの設定が済んでいれば、初心者にも扱いやすい skill です。主なセットアップ負担は外部にあります。つまり、Rube MCP に接続し、Dialpad を認可することです。それが完了すれば、ユーザーは自然言語で目的を伝えられます。ただし、読み取り専用なのか、Dialpad データの変更を許可するのかは明示する必要があります。

この skill を使わないほうがよい場合は？

オフラインの Dialpad ドキュメント、ローカルスクリプト、直接の REST API コーディング、または事前定義された自動化を含む完全パッケージ型ワークフローが必要な場合は、この skill は避けてください。また、組織として AI エージェントによるコミュニケーションツールへのアクセスを許可していない場合や、承認ゲートが必要なのに定義されていない場合にも不向きです。

dialpad-automation skill を改善する方法

目的を明確にして dialpad-automation の結果を改善する

最も効果が大きい改善は、業務上の目的を具体的に書くことです。「Dialpad を管理して」ではなく、「最近の不在着信を探す」「contact を検索する」「message draft を準備する」のように伝えます。具体的なユースケースがあると、RUBE_SEARCH_TOOLS が関連性の高い tools を返しやすくなり、エージェントが過度に広いアクションを選ぶリスクを減らせます。

可能であれば、既知のフィールドも含めてください。

• Account または workspace の文脈
• User または contact の identifiers
• Date ranges
• 読み取り専用か、書き込み意図があるか
• 必要な出力形式

安全ルールと承認ルールを追加する

Dialpad には calls、contacts、messages、communication records が関わる可能性があるため、プロンプトでは検索・参照タスクと、データ変更や相手への連絡を伴うアクションを分けるべきです。次のような指示を追加します。

• “Read-only only”
• “Do not send messages”
• “Ask before creating or updating records”
• “Show the exact tool call before execution”

こうした制約により、コミュニケーション操作にレビューが必要なビジネス環境でも、dialpad-automation をより安全に使えます。

注意すべき一般的な失敗パターン

最も多い問題はセットアップに関するものです。Rube MCP が接続されていない、Dialpad toolkit が有効でない、またはアシスタントが tool discovery を省略してしまうケースです。出力が一般論に見える場合は、続行する前に RUBE_SEARCH_TOOLS の結果と選択された schema を表示するようエージェントに求めてください。

もう一つの失敗パターンは、意図が曖昧すぎることです。「Automate Dialpad」では範囲が広すぎます。エージェントには具体的なタスクと権限境界が必要です。

最初の出力後に反復改善する

初回実行の後は、次の情報を求めてワークフローを改善します。

• 使用された Dialpad tool slug
• 必須および任意の schema fields
• 実行を妨げた不足フィールド
• 次回同じタスクに使える再利用可能なプロンプト
• 書き込み操作向けの、より安全な承認ステップ

これにより、初回結果を単発のエージェント試行で終わらせず、繰り返し使える dialpad-automation workflow にできます。