Skip to main content
Glama
kentaroajisaka

mf-api-mcp

mfc_ca_deleteJournals

Permanently delete journal entries in Money Forward Cloud Accounting. Requires user approval and office code for API key authentication.

Instructions

仕訳を完全削除します(公式MCP未提供・帳簿書き込み。要ユーザー承認)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
office_codeNo対象事業者の事業者番号(XXXX-XXXX)。APIキー認証では必須。MF_OFFICE_CODE を設定していれば省略可

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is a permanent deletion ('完全削除'), a ledger write ('帳簿書き込み'), and requires user approval. This provides key behavioral context for a destructive operation, though it could be more explicit about irreversibility or side effects, which are strongly implied.

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 concise sentence with a parenthetical clause. It is front-loaded with the primary action and includes critical caveats compactly. No wasted words.

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

Completeness3/5

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

For a destructive delete tool with no annotations and no output schema, the description conveys the core behavior (permanent deletion, ledger modification, approval requirement). However, it omits the meaning of the required 'id' parameter and does not specify any response or error behavior. This is adequate but leaves gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 50%: only office_code has a description; id is undocumented. The tool description adds no parameter meaning—it does not clarify what 'id' refers to (likely a journal ID, but not stated). With partial schema coverage, the description should compensate, but it fails to explain any parameter semantics.

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 states the action '仕訳を完全削除します' (completely delete journals) with a specific verb and resource. It is unambiguous about deleting journal entries, but it does not explicitly differentiate from sibling tools like mfc_ca_deleteVouchers, though the resource differs. The parenthetical adds context (not in official MCP, ledger write, requires approval) but doesn't name alternatives.

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 explicit guidance on when to use this tool versus alternatives. It mentions '要ユーザー承認' (requires user approval) as a prerequisite, but there is no 'use when...' or 'use instead of...' information. Usage must be inferred entirely from the tool name and resource type.

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