GooodBilling 公式 MCP Server。Claude Desktop / Cursor 等の MCP 対応クライアントから、AI ファーストで請求書・見積書を操作できます。
「A 社向け Web 制作 30 万円で請求書作って」「保守費 10 万円も追加して」「これで送信して」— PC を開かず、チャットだけで業務を完結できます。
Node.js 18 以上
GooodBilling アカウントと API トークン (発行手順は下記)
Related MCP server: Frihet MCP Server
GooodBilling にログイン
設定 > AI 連携 > API トークン を開く
「新しいトークンを発行」をクリック
用途別テンプレートから選択 (Claude Desktop 推奨スコープを選ぶと簡単)
表示された平文トークン (gb_live_...) を 1 度だけコピー
⚠️ トークンは発行時に 1 度だけしか表示されません。必ずすぐに MCP クライアントの設定に登録してください。
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
mcpServers セクションに以下を追加{
"mcpServers": {
"gooodbilling": {
"command": "npx",
"args": ["-y", "@gooodbilling/mcp-server"],
"env": {
"GOOODBILLING_API_TOKEN": "gb_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}ツールアイコンに gooodbilling が表示されれば成功です。
Claude / ChatGPT 等の AI は、あなたのチャットを 複数の MCP (Gmail / Calendar / Drive / Stripe など) や Web 検索 から拾える状態で受け取ります。「カナリア出版の連絡先教えて」とだけ言われると、AI は GooodBilling の取引先なのか実在出版社なのか判断できず、確認質問されるか Web 検索に流れます。
これを避けるため、セッション最初の 1 発目 だけ以下のヒント語を含めてください。2 発目以降は文脈が確立されるので省略 OK です。
段階 | 例 | プレフィックス必要? |
Tier 1: GooodBilling 固有語 | 請求書 / 未払い / 未入金 / 売掛 / 見積 / 案件 / インボイス | ❌ 不要 (単独で OK) |
Tier 2: 他システムにもある語 | 連絡先 / 売上 / 送信 / 設定 / 取引履歴 | ✅ 必要 |
Tier 3: 固有名詞のみ | 会社名だけ (カナリア出版 等) | ✅ 必要 |
どれか 1 つ含めれば OK:
GooodBillingで / GooodBillingの
請求システムの / 請求管理の
取引先の / 顧客の / 売上先の
AI 連携の (送信機能・設定の文脈)
❌ 曖昧 (Web 検索に流れる / 確認質問される) | ✅ 確実に呼ぶ |
|
|
|
|
|
|
|
|
請求書 未払い 未回収 売掛金 見積 案件 のような Tier 1 語を含む場合はそのまま使えます:
✅ カナリア出版に 5 万円で請求書出して ← 請求書 で確定
✅ 未払いある？ ← 未払い で確定
✅ 未回収教えて ← 未回収 で確定
✅ カナリアの見積一覧見せて ← 見積 で確定
AI クライアントに Stripe など他の請求・決済 MCP が同時接続されていると、Tier 1 単語であっても AI 側がそちらを優先することがあります (「未払い」「請求書」等は Stripe のドメインにも存在するため)。
その環境では 最初の 1 発目に GooodBillingで を付けるのが最も確実:
フレーズ | 起こりうる挙動 (Stripe 併用時) |
| Stripe を優先選択する可能性 |
| Stripe Payments の売上を見に行く |
| Stripe Invoices を優先することがある |
対策の優先順:
ブランド名プレフィックス (最確実): GooodBillingで未払いある？
GooodBilling 固有用語: 売掛金の未回収どう？ / 請求書 (発行側) の未払い見せて
文脈確立: 最初の 1 発に 適格請求書の発行状況 等の業務特化語を使う → 2 発目以降は省略可
クライアント | プレフィックス | 備考 |
Claude Desktop / Cursor | (上記ルール) | ツール権限「常に許可」推奨 |
ChatGPT (Custom GPTs Actions) | 不要 | OpenAPI で 1 API のみ呼ぶため曖昧性なし |
LINE / Slack Bot | 不要 | Bot 実装が GooodBilling API のみ叩く設計 |
Zapier / Make / n8n | 不要 | トリガー/アクションで API 明示。スコープ最小化推奨 |
search_customers — 取引先を検索 (名前・カナ・メール・登録番号)
list_invoices — 請求書一覧 (status / customer / 期間フィルタ)
list_unpaid_invoices — 未入金請求書一覧 (overdue 限定可)
get_invoice — 請求書 1 件詳細
create_invoice_draft — 請求書ドラフト作成 (必ず draft 状態)
update_invoice_draft — ドラフト部分更新 (items 配列全置換)
discard_invoice_draft — ドラフト破棄 (draft 状態のみ)
send_invoice — 取引先へメール送付 (idempotency-key 自動付与)
list_quotes — 見積一覧
get_quote — 見積 1 件詳細
create_quote_draft — 見積ドラフト作成
update_quote_draft — ドラフト部分更新
discard_quote_draft — ドラフト破棄
send_quote — 取引先へメール送付
get_sales_summary — 期間集計 (請求金額・入金額・未入金額)
get_tenant_settings — 送信機能 ON/OFF、BCC 自動付与、既定税率の確認 (read-only)
👤 ユーザー
「A社向けに、Web制作費 30万円で請求書ドラフトを作って」
🤖 Claude
search_customers({query: "A社"}) → cus_xxx (株式会社サンプルA)
create_invoice_draft({customer_id: "cus_xxx", title: "Web 制作費", ...})
→ { id: "inv_yyy", status: "draft", total_amount: 330000, pdf_preview_url: "..." }
「下書きを作成しました。
取引先: 株式会社サンプルA
合計: ¥330,000 (税込)
[PDF を確認する](pdf_preview_url)
内容に問題なければ『送信して』とお伝えください。」
👤 ユーザー
「保守費 10万円も追加して」
🤖 Claude
get_invoice({invoice_id: "inv_yyy"}) → 現状取得
update_invoice_draft({invoice_id: "inv_yyy", items: [Web制作費, 保守費]})
→ total_amount: 440000
「修正しました。保守費 10万円を追加し、合計 ¥440,000 になりました。
[更新後の PDF を確認](pdf_preview_url)」
👤 ユーザー
「OK、送信して」
🤖 Claude
send_invoice({invoice_id: "inv_yyy"}) → status: "sent"
「A社の担当者様 (billing@example.com) へ送付完了しました。
控えがあなたのメールにも届きます。」このセクションは MCP Server を組み込むアプリケーション (LINE Bot, Slack Bot, 音声アシスタント等) の実装者向けです。AI モデルがツール呼出を組み立てる際に守ってほしい原則です。
create_invoice_draft / create_quote_draft に渡す customer_id は、必ず search_customers で取得した実在 ID を使ってください。AI が記憶や推測で UUID を組み立てると 422 invalid_request が返ります。
検索結果が 0 件の場合は、新規取引先を勝手に登録せず、ユーザーに正式名称の確認を促してください。
items[].tax_rate_code は 省略を推奨します。サーバー側が以下の優先順位で自動補完します:
商品マスタの既定税率 (description が一致する場合)
取引先マスタの既定税率
テナント既定税率
標準 10% (STD10)
AI が幻覚で軽減税率を勝手に当てる事故を構造的に避けられます。指定する場合はテナントの税率マスタに登録されたコード (例: STD10, RED8) を渡してください。
update_invoice_draft / update_quote_draft を呼ぶ前に、必ず get_invoice / get_quote で最新状態を取得し、items[] をメモリ上で merge してから PATCH してください。
items[] を含む PATCH は配列全置換のため、merge を怠ると既存明細が失われます。
send_invoice / send_quote は 取引先へメール送付を実行し、取り消し不可です。
呼出前に必ず pdf_preview_url をユーザーに提示し、明示同意 (「送信して」「OK」等) を取得してください。AI が単独判断で送信することは避けてください。
送信系ツールは idempotency_key を省略可能です。MCP Server が UUID を自動生成して付与します。
同一送信意図 (例: ユーザーが「送信」と 2 回連続で入力した場合) では、同じ idempotency_key を渡すと二重送信が構造的に防止されます。
discard_invoice_draft / discard_quote_draft は draft 状態の書類のみを破棄できます。
確定済 (issued / sent / paid) 書類の取消は API では行わず、ユーザーに「Web 画面での赤伝処理が必要」と案内してください。
変数 | 必須 | 既定値 | 説明 |
| ✅ | — | API トークン ( |
| ❌ |
| API ベース URL (セルフホスト / staging 用) |
FATAL: GOOODBILLING_API_TOKEN is not set で起動失敗→ MCP クライアント設定の env セクションにトークンが正しく設定されているか確認してください。
invalid_token が返る→ トークンが失効済 / 期限切れの可能性。管理画面で再発行してください。
insufficient_scope が返る→ トークンに必要なスコープが付与されていません (例: send_invoice には emails:send + invoices:write が必要)。管理画面でスコープを確認し、不足があれば再発行してください。
send_disabled_by_tenant が返る→ テナント管理者が「AI / API 経由送信」を一時停止しています。管理画面 設定 > AI 連携 > API トークン > 送信設定 で有効化してください。
customer_email_missing が返る→ 取引先の担当者にメールアドレスが登録されていません。Web 画面で取引先担当者のメールを設定するか、send_invoice の to パラメータで明示指定してください。
MIT
請求書を新規作成 (status=draft)。
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | ||
| case_id | No | 任意。未指定時はサーバーが自動解決 | |
| title | Yes | ||
| issue_date | Yes | ||
| due_date | Yes | ||
| items | Yes | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions 'status=draft' and does not address side effects, required permissions, or output behavior, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence) with no wasted words. However, it is under-specified and lacks structure, such as separating purpose from behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, no annotations, and a low schema description coverage, the description is critically incomplete. It does not explain the return value, prerequisites, or how the draft is created, making it inadequate for reliable tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, and the tool description adds no additional meaning to any parameter. The description is generic and does not clarify the role of parameters like 'tax_rate_code' or 'case_id' beyond what the schema barely provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it creates a new invoice with status draft, which is a clear verb+resource combination. However, it does not distinguish from sibling tools like 'create_quote_draft', so a slight deduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'create_quote_draft' or 'update_invoice_draft'. The description lacks any contextual instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積書を新規作成 (status=draft)。
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | ||
| case_id | No | ||
| title | Yes | ||
| issue_date | Yes | ||
| expiry_date | Yes | 有効期限 | |
| items | Yes | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It reveals that the quote status is draft, but with no annotations, it fails to disclose any side effects, authentication needs, or post-creation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one sentence), but it sacrifices necessary detail, bordering on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no annotations or output schema, the description is too minimal to guide an agent effectively; it omits expected outcomes and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to parameters beyond the single schema description; with low schema coverage (14%), it should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '新規作成' (create) and resource '見積書' (quotation), and specifies the status as draft, distinguishing it from invoice creation and update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; it does not explain when to use this tool versus siblings like 'create_invoice_draft' or 'update_quote_draft'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
請求書ドラフトを破棄。
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Discard' implies mutation but does not specify if the action is reversible, what permissions are required, or any side effects (e.g., cascade effects on related data). This omission leaves the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (a single phrase), but it sacrifices necessary detail. While brevity is valued, under-specification reduces its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description fails to provide essential context such as action consequences, prerequisites, or return values. The tool is simple (one param), but the description is still insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 0% description coverage. The description does not explain the role of 'invoice_id' beyond its existence in the schema. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'discard' and the resource 'invoice draft', making the action unambiguous. However, it does not explicitly differentiate from siblings like 'discard_quote_draft' or 'create_invoice_draft', but the resource differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update_invoice_draft' or 'send_invoice'. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積書ドラフトを破棄。
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only states 'discard' without detailing consequences (e.g., irreversibility, required permissions, side effects). For a destructive action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to provide essential information. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one required param, no output schema), the description does not cover basic usage context or clarify what 'discard' entails, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain the parameter quote_id, but it does not. No meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '見積書ドラフトを破棄。' clearly states the action (discard) and the target resource (quote draft), matching the tool name. However, it does not differentiate from the sibling tool 'discard_invoice_draft' which has an identical pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like discard_invoice_draft. The description lacks context or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
請求書の詳細。
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description minimally implies a read operation through 'details', but lacks explicit disclosure of safety, side effects, or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but underspecified; conciseness is beneficial but sacrifices necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description fails to cover return values, error cases, or operational context for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the invoice_id parameter beyond its existence and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '請求書の詳細' clearly indicates the tool retrieves invoice details, but it does not distinguish it from sibling tools like get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs alternatives such as list_invoices or get_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積書の詳細。
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral details. It does not disclose that this is a read-only operation, what the response format is, or any authorization requirements. With no annotations, the tool's behavior is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase. While it is not verbose, it is so brief that it sacrifices informativeness. For a simple tool, conciseness is good, but here it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is severely incomplete. The agent has no information about return values, error states, or behavior. Even for a trivial get-by-ID tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines quote_id as a required UUID, but the description provides no explanation of this parameter. Schema description coverage is 0%, and the agent must infer its purpose from the parameter name alone. The description adds zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '見積書の詳細。' ('Quote details.') indicates the tool retrieves details for a quote. However, it does not explicitly state that it gets a single quote by ID, nor does it distinguish from sibling tools like list_quotes or get_invoice. The purpose is understood but not clearly articulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over alternatives such as list_quotes (for listing) or update_quote_draft (for modification). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
売上集計 (期間指定)。
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | 集計開始日 (発行日基準) | |
| to | Yes | 集計終了日 (発行日基準) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, authentication requirements, or whether the tool aggregates all invoices or only certain types. The minimal description leaves the agent uninformed about key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, which is good for conciseness. However, it lacks necessary details, making it too minimal rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., aggregated totals, breakdowns). It only says 'sales summary' without elaboration. This is insufficient for a tool that likely returns structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions (100% coverage) for both parameters ('from' and 'to'), explaining they are date ranges based on issue date. The tool description adds no extra meaning beyond this, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: summarizing sales over a specified period. It uses a verb (売上集計, meaning 'sales summary') and resource (sales), and distinguishes from sibling tools which are invoicing-specific. The brief wording is clear but could be more explicit about the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or when not to use it. The sibling tools are all about invoices and quotes, so the context is somewhat implied, but explicit direction is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
テナント設定 (送信機能 ON/OFF) を取得。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the tool gets settings but does not disclose authentication requirements, error behavior, or what happens if settings are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is minimal but adequate. It lacks details about the return format and any other settings beyond the send function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds some meaning by specifying 'send function ON/OFF' but does not fully explain the return structure or other possible settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves tenant settings, specifically the send function ON/OFF. It is a specific verb-resource pair and distinct from sibling tools dealing with invoices and quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not provide context about prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
請求書の一覧。
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| customer_id | No | ||
| from | No | ||
| to | No | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. The short phrase does not disclose behavior such as pagination (cursor, limit), filtering parameters, or response format. For a list tool, key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short phrase), which is efficient, but it omits essential details needed for correct tool usage. It is front-loaded but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (6 optional parameters, no output schema, 15 sibling tools), the description is severely incomplete. It fails to explain filtering, pagination, or the result structure that the agent needs to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 6 parameters with 0% description coverage, meaning no parameter descriptions exist. The tool description adds no information about what any parameter does, leaving the agent with only parameter names and types (and enum values) to infer usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List of invoices' which identifies the basic purpose, but lacks specificity to distinguish from sibling tools like list_unpaid_invoices or list_quotes. The verb 'list' is clear, but the resource scope is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_unpaid_invoices or search_customers. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積書の一覧。
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| customer_id | No | ||
| from | No | ||
| to | No | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits: no mention of pagination, filtering, or what happens with empty results. The schema implies filtering but description offers no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (just one short phrase), but it sacrifices necessary information. While front-loaded, it fails to earn its place by conveying essential details for a tool with multiple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no schema descriptions, no output schema, and no annotations, the single phrase is completely inadequate. The description provides almost no context for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 6 parameters. The agent must rely solely on parameter names and types without any semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List of quotes' clearly indicating verb and resource, but it is vague and does not differentiate from sibling tools like 'list_invoices' or 'get_quote'. No scope or filtering hints are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_quote' or 'list_invoices'. No prerequisites, exclusions, or usage context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
未払い請求書の一覧。
| Name | Required | Description | Default |
|---|---|---|---|
| overdue_only | No | 期日超過分のみ取得 (既定: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure but only states 'list of unpaid invoices'. It omits whether the output is a list, supports pagination, sorting, or any side effects. No behavioral traits are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and adds no value beyond the name. It does not earn its place as it fails to inform the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and a simple parameter, the description should at least indicate the return structure (e.g., a list of invoices). Lacking that, it is incomplete and insufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter 'overdue_only' with a description, so baseline is 3. The tool description adds no extra meaning beyond the schema's own documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description '未払い請求書の一覧' (List of unpaid invoices) merely restates the tool name in Japanese, providing no additional clarity beyond the English name. It does not differentiate from sibling tool 'list_invoices' except through the name itself, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_invoices' or 'get_invoice'. The description lacks any indication of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取引先を検索する。
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 顧客名・略称・メール・登録番号への部分一致検索キーワード | |
| contact_name | No | 担当者氏名で絞り込み (例: 「山田」「佐藤」) | |
| limit | No | 取得件数 (既定: 20, 上限: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It correctly indicates a read operation (search) but does not disclose further behavioral traits such as rate limits, pagination, or sorting. Acceptable for a simple search but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. It is concise and efficient, though it could be slightly expanded to improve completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (3 params, no output schema), the description is mostly adequate but lacks mention of return format, default behavior, or edge cases. Acceptable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional meaning beyond the schema; the schema already details each parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'search for business partners,' identifying the verb and resource. It distinguishes from sibling tools which are all invoice/quote related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but the context of sibling tools implies this is the dedicated customer search tool. No when-not or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ 取引先に請求書メールを送付する (取り消し不可)。送信前にユーザーへ宛先メールアドレス・請求書金額・添付 PDF の最終確認を取ること。subject / body / to / cc / bcc は通常省略する (システムが自動で組み立てる)。ユーザーが明示的に上書き指定した場合のみ含め、その時だけ確認文に含めること。失敗時: 403=テナント送信機能 OFF (get_tenant_settings で確認可) / 422=取引先メアド未登録 / 409=送信済。冪等性キーは省略可 (自動生成、二重送信防止)。
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | ||
| idempotency_key | No | ||
| to | No | ||
| cc | No | ||
| bcc | No | ||
| subject | No | ||
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses irreversibility, pre-send confirmation requirements, error scenarios (403, 422, 409), idempotency key usage to prevent duplicates. This fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (few sentences), front-loads the core purpose and irreversibility, then provides structured guidelines. No redundant phrases; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers purpose, irreversibility, pre-send confirmation, parameter usage, error handling, and idempotency. It is highly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds crucial context: parameters like subject/body/to/cc/bcc are normally omitted and included only when user explicitly overrides; idempotency_key is optional and auto-generated; invoice_id is required. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an invoice email to a customer and that the action is irreversible. It uses a specific verb ('send') and resource ('invoice'), distinguishing it from siblings like send_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: confirm destination email, amount, and attached PDF before sending; normally omit subject/body/cc/bcc; error handling with status codes and checks (e.g., get_tenant_settings). It lacks direct comparison with siblings but implies it's for final sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ 取引先に見積書メールを送付する (取り消し不可)。送信前にユーザーへ宛先メールアドレス・見積金額・添付 PDF の最終確認を取ること。subject / body / to / cc / bcc は通常省略する (システムが自動で組み立てる)。ユーザーが明示的に上書き指定した場合のみ含め、その時だけ確認文に含めること。失敗時: 403=テナント送信機能 OFF (get_tenant_settings で確認可) / 422=取引先メアド未登録。冪等性キーは省略可。
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| idempotency_key | No | ||
| to | No | ||
| cc | No | ||
| bcc | No | ||
| subject | No | ||
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states irreversibility (取り消し不可), error scenarios (403, 422), and optional idempotency key. This covers key behavioral traits beyond the basic action of sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, well-organized paragraph with warning first, then action, usage notes, and error codes. Every sentence adds value, though it could be slightly more structured (e.g., bullet points) for scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description provides necessary context: action, default behavior, error handling, and a prerequisite (get_tenant_settings). Does not detail return values or rate limits, but is fairly complete for a send email tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0%, so description must compensate for 7 parameters. It explains that subject/body/to/cc/bcc are typically omitted and idempotency_key is optional, but does not describe quote_id or the exact purpose of each field. Adds some value but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sends a quote email to a client, emphasizing irreversibility. The verb '送付する' (send) and resource '見積書' (quote) are specific, distinguishing it from sibling tools like send_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: confirm details before sending, note that subject/body/to/cc/bcc are usually auto-built, and list error codes with cross-reference to get_tenant_settings. Lacks explicit when-not-to-use relative to siblings, but sufficiently guides typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
請求書ドラフトを更新。
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | ||
| customer_id | No | 変更時は case_id が新顧客向けに再解決される | |
| case_id | No | ||
| title | No | ||
| issue_date | No | ||
| due_date | No | ||
| items | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Description does not disclose side effects (e.g., whether case_id re-resolution occurs), permissions needed, or limitations. Only implicit behavioral hints exist in parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence), but at the cost of completeness. Adequate for a brief label, but not rich enough for effective tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and minimal description. Missing information about return values, error conditions, and operational context (e.g., draft lifecycle).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (13%), but the tool description does not add any parameter explanations. It relies entirely on the schema's sparse descriptions for customer_id and tax_rate_code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update invoice draft' which is a specific verb+resource. It distinguishes from sibling tools like create_invoice_draft and discard_invoice_draft by implication of the name, but does not elaborate on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, exclusions, or context such as requiring the invoice to be in draft status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積書ドラフトを更新。
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| customer_id | No | ||
| case_id | No | ||
| title | No | ||
| issue_date | No | ||
| expiry_date | No | ||
| items | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only says 'update' without explaining whether partial updates are allowed, what happens to existing data, or any side effects like transactions or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but underspecified. While no filler exists, the single sentence fails to convey necessary information for an AI agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is woefully incomplete. It does not clarify update behavior, required fields beyond quote_id, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds no information about parameters. Only tax_rate_code has a schema description, and the tool description itself is silent on parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (quote draft), distinguishing it from create and discard siblings. However, it is very brief and does not provide additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_quote_draft or discard_quote_draft. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.14create_invoice_draftcreate_quote_draftdiscard_invoice_draftdiscard_quote_draftget_invoiceget_quoteget_sales_summaryget_tenant_settingslist_invoiceslist_quoteslist_unpaid_invoicessearch_customerssend_invoicesend_quoteupdate_invoice_draftupdate_quote_draftEvery tool targets a distinct resource (invoice vs quote) and action (create draft, get, list, update draft, discard draft, send). Even list_unpaid_invoices is clearly a filtered variant of list_invoices, not a duplicate.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_invoice_draft, send_quote, get_tenant_settings). No mixing of conventions or vague verbs.
16 tools cover the core workflows for invoices and quotes (draft, update, discard, send, list, get) plus supporting operations (search customers, get settings, sales summary). This is well-scoped for a dedicated billing server.
While the draft-to-send lifecycle is covered, notable gaps exist: no payment recording, no invoice finalization beyond sending, no conversion of quotes to invoices, and no tool to delete sent documents. The sales summary tool suggests revenue tracking, yet payment handling is missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Chilean DTE/SII invoicing — issue invoices, reconcile payments and manage clients with AI agents.
Taiwan payments (ECPay 綠界 + NewebPay 藍新) & e-invoices for AI agents. Stateless, never holds funds.
Connect your AI to your Well financial data - invoices, companies, contacts.
Let your AI send invoices and take payment — card or ACH. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gooodbilling/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
