MF Invoice MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions (e.g., create, get, list, update for billings, quotes, partners, items). However, mf_create_billing and mf_create_billing_from_quote have some overlap in functionality, and mf_convert_quote_to_billing might be confused with mf_create_billing_from_quote, though descriptions clarify differences.
Naming Consistency5/5
All tools follow a consistent mf_verb_noun pattern with snake_case throughout. Verbs like create, get, list, update, download are used predictably across resources, making the naming highly uniform and readable.
Tool Count3/5
With 22 tools, the count is borderline high for an invoice management server, potentially feeling heavy. However, it covers authentication, multiple resources (billings, quotes, partners, items), and CRUD operations, which might justify the number given the domain complexity.
Completeness4/5
The tool set provides comprehensive coverage for invoice and quote management, including CRUD operations, PDF downloads, and authentication flows. A minor gap is the unsupported mf_create_delivery_slip tool, and there's no delete functionality for resources, but agents can likely work around this with updates or external methods.
Average 3/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 only states that it retrieves detailed information, without mentioning any behavioral traits such as read-only nature (implied by 'get'), potential authentication needs, rate limits, error handling, or what 'detailed information' entails. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese ('品目の詳細情報を取得します'), which is appropriately concise and front-loaded with the core purpose. There's no wasted text, making it easy to parse, though it could benefit from more detail given the lack of annotations.
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's complexity (a read operation with one parameter), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral context. For a tool in this context, more information is needed to adequately guide an AI agent.
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 input schema has 100% description coverage (the 'item_id' parameter is described as '品目ID'), so the schema already documents the parameter fully. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as '品目の詳細情報を取得します' (retrieves detailed information of an item), which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'mf_list_items' (which likely lists items rather than getting details of a specific one), making it vague about differentiation. The purpose is understandable but lacks sibling context.
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 when to use 'mf_get_item' (for a specific item's details) compared to 'mf_list_items' (for listing items) or other sibling tools, nor does it specify any prerequisites or exclusions. This leaves usage entirely implied from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states it's a read operation ('取得します' - get), implying it's likely safe and non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., fields, format). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese, front-loaded with the core action. It's appropriately sized for a simple tool, though it could be more informative without losing conciseness.
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 a simple input schema, the description is incomplete. It doesn't cover what 'detailed information' means (output), authentication needs, or usage context, making it inadequate for an agent to fully understand the tool's behavior and application.
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 description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage with a clear description for 'partner_id' ('取引先ID' - partner ID), so the baseline is 3. The tool description doesn't explain the parameter's role or constraints (e.g., format, source).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取引先の詳細情報を取得します' (Get detailed information of a partner) clearly states the verb ('取得します' - get) and resource ('取引先' - partner), but it's vague about what 'detailed information' entails. It doesn't distinguish from sibling tools like 'mf_list_partners' (which likely lists partners) or 'mf_get_billing' (which gets billing details).
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 prerequisites (e.g., authentication), differentiate from 'mf_list_partners' (for listing vs. getting details), or specify use cases (e.g., retrieving a specific partner by ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. '更新します' (updates) implies a mutation operation, but the description doesn't specify required permissions, whether updates are partial or full, what happens to unspecified fields, or any side effects. The items parameter description hints at '全置換' (full replacement), but this is buried in the schema, not the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence. It's front-loaded with the core action. However, for a complex mutation tool with 11 parameters, this brevity borders on under-specification rather than optimal conciseness.
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?
For a mutation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'updating' entails operationally, what permissions are needed, how errors are handled, or what the response contains. The agent must rely entirely on the input schema without contextual guidance.
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?
Schema description coverage is 100%, with all parameters well-documented in Japanese. The tool description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '請求書を更新します' (Updates an invoice) states a clear verb ('更新します' - updates) and resource ('請求書' - invoice), providing basic purpose. However, it doesn't distinguish this from sibling tools like mf_update_payment_status or mf_update_quote, nor does it specify what aspects of an invoice can be updated beyond the generic term.
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. There are no explicit instructions on prerequisites (e.g., needing an existing billing_id), when to choose this over mf_create_billing, or how it differs from mf_update_payment_status. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('updates a quote') without disclosing behavioral traits. It doesn't mention whether this is a destructive operation, what permissions are required, how errors are handled, or what the response looks like (since no output schema exists). This is inadequate for a mutation tool with zero 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 extremely concise with a single sentence ('見積書を更新します'), which is front-loaded and wastes no words. For a tool with a well-documented schema, this brevity is appropriate, though it may sacrifice completeness.
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 (6 parameters, nested items array, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain the tool's behavior, return values, or usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly beyond the basic schema.
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 (e.g., quote_id, items with full replacement). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '見積書を更新します' (Updates a quote) clearly states the verb (update) and resource (quote), but it's quite generic and doesn't differentiate from sibling tools like mf_update_billing or specify what aspects of a quote can be updated. It avoids being a tautology with the name (mf_update_quote), but lacks specificity about scope.
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 guidance is provided on when to use this tool versus alternatives like mf_create_quote or mf_get_quote, nor are there any prerequisites mentioned (e.g., needing an existing quote_id). The description implies usage for updates but offers no context about constraints or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'gets an access token,' implying a read operation, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what the output looks like (e.g., token format, expiration). For a security-sensitive tool with zero annotation coverage, this is a significant gap.
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 function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
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's complexity (authentication-related, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., security implications, error responses), usage context relative to siblings, and output information. For a tool that likely returns a token, the absence of an output schema means the description should compensate by explaining the return value, which it doesn't.
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 description mentions 'using an authentication code,' which aligns with the single parameter 'code' in the input schema. Since schema description coverage is 100% (the schema fully documents the parameter), the description adds minimal value beyond what's already in the structured data. The baseline score of 3 reflects adequate but not enhanced 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 clearly states the tool's purpose: 'get an access token using an authentication code.' It specifies the verb ('get') and resource ('access token'), and mentions the required input ('authentication code'). However, it doesn't explicitly differentiate from sibling tools like 'mf_auth_start' or 'mf_refresh_token', which likely handle different authentication steps or token renewal.
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 prerequisites (e.g., after 'mf_auth_start'), exclusions, or how it relates to siblings like 'mf_refresh_token' for token renewal. Without such context, an agent might struggle to select the correct tool in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 checks authentication status, implying a read-only operation, but doesn't specify what the check entails (e.g., whether it validates tokens, returns user info, or indicates session validity). It also lacks details on permissions, rate limits, or error handling, which are critical for a tool dealing with authentication. The description is too vague to fully inform agent behavior.
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 ('認証状態を確認します') that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core function, making it easy for an agent to parse quickly. Every part of the sentence earns its place by delivering essential information.
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 authentication tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a boolean status, token details, or error messages), which is crucial for an agent to understand the result. Without this, the agent cannot properly handle the tool's output or integrate it into workflows, leaving significant gaps in usability.
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 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required, but it also doesn't compensate for any gaps since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '認証状態を確認します' (checks authentication status) states a clear verb ('checks') and resource ('authentication status'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'mf_auth_start' or 'mf_refresh_token', which are also related to authentication but serve different functions. The purpose is understandable but lacks specificity about what aspect of authentication status is being checked.
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 prerequisites (e.g., whether it requires prior authentication steps), exclusions, or how it compares to siblings like 'mf_auth_start' (which likely initiates authentication) or 'mf_refresh_token' (which might renew tokens). Without such context, an agent might struggle to select this tool appropriately in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the conversion action but fails to mention critical details like whether this is a read-only or destructive operation, permission requirements, rate limits, or what the output entails (e.g., creates a new billing record). This leaves significant gaps in understanding the tool's behavior.
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 function without any unnecessary words. It is front-loaded and appropriately sized for its purpose, making it highly concise and well-structured.
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 converting a quote to a billing (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits, output format, error handling, or how it differs from sibling tools, making it incomplete for effective agent use.
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 description does not add any parameter-specific information beyond what the input schema provides. Since the schema description coverage is 100% (the 'quote_id' parameter is documented as '見積書ID'), the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.
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 ('convert') and the resources involved ('quote to billing'), making the purpose understandable. However, it doesn't differentiate this tool from the sibling tool 'mf_create_billing_from_quote', which appears to serve a similar function, preventing a perfect score.
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 like 'mf_create_billing_from_quote' or 'mf_create_billing'. It lacks context about prerequisites, such as needing a valid quote ID, or any exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 creates invoices but doesn't mention whether this is a write operation (implied), what permissions are needed, if it's idempotent, or what happens on success/failure (e.g., returns an ID or error). For a creation tool with zero annotation coverage, this is a significant gap in transparency.
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 front-loads the core purpose. It wastes no words and directly states what the tool does. Every part of the sentence earns its place by specifying the action and compliance context.
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 (8 parameters, nested items array, no output schema, and no annotations), the description is incomplete. It doesn't explain the invoice system context, what 'インボイス制度対応' entails, or the expected output (e.g., a billing ID or confirmation). For a creation tool with significant input structure, more context is needed to guide the agent effectively.
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 description adds no parameter-specific information beyond what's in the schema. However, schema description coverage is 100%, with all 8 parameters and nested items well-documented in Japanese (e.g., partner_id as '取引先ID（必須）', excise enum explained). The baseline is 3 when the schema does the heavy lifting, and the description doesn't compensate with additional context like format examples or business rules.
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: 'インボイス制度対応の請求書を作成します' (creates invoices compliant with the invoice system). It specifies the verb '作成します' (creates) and resource '請求書' (invoices), and distinguishes from siblings like mf_create_quote or mf_create_delivery_slip by focusing on billing. However, it doesn't explicitly differentiate from mf_create_billing_from_quote or mf_convert_quote_to_billing, which are also billing-related.
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 prerequisites (e.g., authentication), when to choose this over mf_create_billing_from_quote, or any constraints (e.g., only for new invoices). Without such context, the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates an invoice from a quote but doesn't mention whether this is a mutating operation, what permissions are required, whether the quote is modified, what happens on failure, or what the response contains. For a creation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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?
For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what side effects occur, or how it differs from similar sibling tools. The 100% schema coverage helps with parameters, but overall context for proper tool selection and invocation is lacking.
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?
Schema description coverage is 100%, providing clear documentation for all 7 parameters. The description doesn't add any additional parameter semantics beyond what's in the schema, but the schema adequately covers parameter purposes and formats. The baseline score of 3 reflects that 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 action ('作成します' - creates) and resource ('請求書' - invoice) from a source ('見積書から' - from quote). It's specific about the transformation process but doesn't explicitly differentiate from sibling tools like 'mf_convert_quote_to_billing' which appears to serve a similar purpose.
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 guidance is provided about when to use this tool versus alternatives like 'mf_convert_quote_to_billing' or 'mf_create_billing'. The description only states what the tool does without indicating appropriate contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While '作成します' (creates) implies a write/mutation operation, the description doesn't mention permissions required, whether this is a transactional operation, what happens on failure, or what the expected output format is. For a creation tool with zero annotation coverage, this is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with good schema documentation and is perfectly front-loaded with the core functionality.
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?
For a creation tool with 6 parameters (4 required) and no output schema, the description is too minimal. It doesn't explain what happens after creation, whether the quote gets saved to a database, if it's immediately available for download/processing, or how it relates to the broader workflow with billing tools. The 'invoice system compliance' hint is useful but insufficient for full contextual understanding.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'インボイス制度対応' (invoice system compliance) which provides some context about the quote's purpose, but doesn't explain how this relates to specific parameters like excise tax settings.
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: 'インボイス制度対応の見積書を作成します' (creates an invoice system-compliant quote). It specifies both the verb (creates) and resource (quote), but doesn't explicitly differentiate it from sibling tools like mf_create_billing or mf_convert_quote_to_billing, which would require a 5.
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. There are multiple related tools (mf_create_billing, mf_convert_quote_to_billing, mf_create_billing_from_quote) but no indication of when this quote creation tool is appropriate versus those billing tools. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action (get PDF URL) but doesn't describe traits like whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or the format of the returned URL. For a tool with no annotation coverage, this is a significant gap in transparency.
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 without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy to parse quickly.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on behavioral traits (e.g., safety, authentication), output format, or error handling. For a tool that retrieves URLs, more context on what the URL represents (e.g., temporary, downloadable) would be helpful, but it's missing.
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 input schema has 100% description coverage (billing_id is documented as '請求書ID' meaning 'invoice ID'), so the baseline is 3. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. It compensates minimally by implying the parameter is needed but doesn't enhance 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 clearly states the tool's purpose: '請求書のPDF URLを取得します' translates to 'Get the PDF URL of an invoice.' This specifies the verb (get/retrieve) and resource (invoice PDF URL). It distinguishes from siblings like mf_get_billing (which likely returns billing data) and mf_download_quote_pdf (which handles quotes), but doesn't explicitly differentiate from other PDF-related tools beyond the resource type.
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 prerequisites (e.g., needing a valid billing_id), exclusions, or comparisons to siblings like mf_get_billing (which might return metadata) or mf_list_billings (for listing). Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states what the tool does but doesn't disclose whether this is a read-only operation, if it requires authentication, what format the URL returns in, or any rate limits. For a tool that presumably accesses external resources, this is inadequate disclosure.
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 that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.
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?
For a tool that retrieves PDF URLs (potentially involving external resources and authentication), the description is insufficient. With no annotations and no output schema, it doesn't explain what the return value looks like (e.g., URL format, expiration), authentication requirements, or error conditions. The description alone doesn't provide enough context for safe and effective use.
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?
Schema description coverage is 100%, so the single parameter 'quote_id' is fully documented in the schema. The description doesn't add any additional parameter context beyond what's already in the schema, which meets the baseline expectation when schema coverage is complete.
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 resource ('見積書のPDF URL' - quote PDF URL), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling 'mf_download_billing_pdf' which handles billing PDFs, but the distinction is reasonably implied through the resource name.
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 like 'mf_get_quote' (which might return quote data without PDF) or 'mf_download_billing_pdf' (for billing documents). There's no mention of prerequisites, such as needing an existing quote ID from another operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 information, implying it's a read-only operation, but doesn't clarify aspects like authentication requirements, error handling (e.g., invalid billing_id), rate limits, or what '詳細情報' (detailed information) includes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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: '請求書の詳細情報を取得します'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple retrieval tool. Every part of the sentence directly contributes to understanding the tool's function.
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 (a retrieval tool with no output schema and no annotations), the description is incomplete. It doesn't explain what '詳細情報' includes (e.g., fields returned), error conditions, or authentication needs. Without annotations or an output schema, the description should provide more context to help the agent use the tool effectively, but it falls short.
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 input schema has 100% description coverage, with the billing_id parameter documented as '請求書ID' (invoice ID). The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily supplement the 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 tool's purpose: '請求書の詳細情報を取得します' (retrieves detailed information of an invoice). It specifies the verb '取得します' (retrieves) and the resource '請求書の詳細情報' (invoice details). However, it doesn't explicitly differentiate from sibling tools like mf_list_billings (which lists multiple invoices) or mf_get_quote (which retrieves quote details), though the resource specificity helps somewhat.
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 prerequisites (e.g., needing a billing_id), contrast with mf_list_billings for listing multiple invoices, or specify use cases like viewing specific invoice details after listing. Without such context, the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '取得します' (retrieve) implies a read-only operation, the description doesn't explicitly state whether this requires authentication, what permissions are needed, whether there are rate limits, or what format the response takes. For a tool with no annotation coverage, this is inadequate behavioral transparency.
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 that states the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place.
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 that this is a retrieval tool with no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't help the agent understand what '詳細情報' (detailed information) includes, how this differs from mf_list_quotes, or what authentication/authorization is required. The description should provide more context for proper tool selection and usage.
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 has 100% description coverage with a clear parameter description ('見積書ID' - quote ID). The tool description doesn't add any parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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: retrieving detailed information about a quote/estimate. It uses a specific verb ('取得します' - retrieve/get) and resource ('見積書' - quote/estimate). However, it doesn't distinguish this from sibling tools like mf_list_quotes or mf_get_billing, which would require a 5.
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. There are multiple related tools (mf_list_quotes, mf_get_billing, mf_get_item, mf_get_partner) that likely serve similar purposes for different resources, but the description doesn't help the agent choose between them. No explicit when/when-not instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions filtering capability but doesn't describe pagination behavior (implied by page/per_page parameters), rate limits, authentication requirements, error conditions, or what the return format looks like. For a list retrieval tool with zero annotation coverage, this leaves significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences that communicate the core functionality. The first sentence states the primary purpose, and the second adds important filtering capability. There's no wasted verbiage or redundant information.
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?
For a list retrieval tool with 3 parameters and no output schema, the description is insufficiently complete. It doesn't explain what an 'item' represents in this context, what fields are returned, how pagination works, or any authentication requirements. The lack of output schema means the description should ideally provide some indication of return format, but it doesn't.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (page, per_page, q) with their types and descriptions. The description adds minimal value beyond the schema by mentioning keyword filtering ('検索キーワードで絞り込み可能です'), which aligns with the 'q' parameter. However, it doesn't provide additional context about parameter interactions or constraints beyond what's in the 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 verb ('取得します' - get/retrieve) and resource ('品目一覧' - item list), making the purpose immediately understandable. It also mentions filtering capability ('検索キーワードで絞り込み可能です'), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like mf_get_item, which appears to retrieve a single item rather than a list.
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 when to use mf_list_items versus mf_get_item (for single item retrieval) or other list tools like mf_list_billings, mf_list_partners, or mf_list_quotes. There's no context about prerequisites, typical use cases, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the filtering capability but doesn't describe important behavioral aspects: whether this is a read-only operation, what the return format looks like (list structure), pagination behavior (implied by parameters but not explained), authentication requirements, rate limits, or error conditions. For a list operation with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with just two sentences that directly state the tool's purpose and main capability. There's no wasted verbiage or unnecessary information. However, it could be slightly more front-loaded by explicitly stating it's a list/retrieval operation first.
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 no annotations, no output schema, and a list operation with pagination parameters, the description is incomplete. It doesn't explain what the tool returns (partner list structure), how pagination works, authentication requirements, or error handling. For a tool that likely returns structured data with multiple records, this leaves significant gaps for an AI agent to understand how to properly use and interpret results.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (page, per_page, q) with their descriptions. The description mentions filtering ('検索キーワードで絞り込み可能です') which corresponds to the 'q' parameter, but adds no additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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 verb ('取得します' - get/retrieve) and resource ('取引先一覧' - partner list), making the purpose immediately understandable. It also mentions filtering capability ('検索キーワードで絞り込み可能です'), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like mf_get_partner or other list tools (mf_list_billings, mf_list_items, mf_list_quotes).
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 when to use mf_list_partners versus mf_get_partner (for individual partner details), nor does it provide context about prerequisites, limitations, or appropriate use cases. The only usage hint is the filtering capability, but this doesn't constitute proper guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While '更新します' (updates) implies a mutation operation, the description doesn't disclose important behavioral traits like required permissions, whether this is a destructive change, rate limits, or what happens when payment status is changed. For a mutation tool with zero annotation coverage, this is inadequate.
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 that gets straight to the point with zero wasted words. It's appropriately sized for the tool's function and front-loads the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what happens when payment status is updated, potential side effects, or error conditions. Given the complexity of updating payment status (which likely has business logic implications), the description should provide more context about the operation's behavior and consequences.
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 both parameters clearly documented in the schema (billing_id and payment_status with enum values). The description doesn't add any meaningful parameter semantics beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate.
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 ('更新します' - updates) and resource ('請求書の入金状態' - invoice payment status), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'mf_update_billing' or 'mf_update_quote', which might also update invoice-related data.
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. There are multiple sibling tools that might handle invoice updates (mf_update_billing, mf_convert_quote_to_billing), but the description doesn't explain when this specific payment status update tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 action but doesn't explain what 'refreshing' entails—whether it requires existing credentials, returns a new token, has side effects like invalidating old tokens, or involves rate limits. For a security-sensitive operation, this is a significant gap.
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 with zero waste. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.
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 token refresh (a security operation) and the lack of annotations and output schema, the description is incomplete. It doesn't cover what the tool returns (e.g., a new token), error conditions, or dependencies on other tools. This leaves critical context missing for an AI agent.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param details, which is appropriate, but it also doesn't compensate for any gaps (none exist). A baseline of 4 is given since no parameters are present.
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: 'アクセストークンをリフレッシュします' (refreshes an access token). It uses a specific verb ('リフレッシュします') and identifies the resource ('アクセストークン'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'mf_auth_start' or 'mf_auth_status', which prevents a perfect score.
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 prerequisites (e.g., needing an expired token), timing (e.g., after authentication), or related tools like 'mf_auth_start' for initial auth. This lack of context leaves usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions filtering capabilities but doesn't disclose critical behavioral traits: whether this is a read-only operation, if it requires authentication, pagination behavior (implied by page/per_page parameters but not explained), rate limits, or what the return format looks like. For a list operation with 7 parameters, this leaves significant gaps.
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 extremely concise - just two short sentences in Japanese that state the core purpose and key filtering capabilities. Every word earns its place with zero redundancy or fluff. It's appropriately sized for a list operation.
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's complexity (7 parameters, list operation) and lack of both annotations and output schema, the description is insufficient. It doesn't explain what the return value contains, how pagination works, authentication requirements, or error conditions. For a billing/list tool in what appears to be a financial system, more contextual information would be expected.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by mentioning partner and period filtering (which corresponds to partner_id, from, and to parameters), but doesn't provide additional context about parameter interactions, default values, or usage examples.
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: '請求書一覧を取得します' (get a list of invoices). It specifies the resource (invoices) and the action (get/list), but doesn't explicitly differentiate it from sibling tools like mf_get_billing (which likely retrieves a single invoice) or mf_list_quotes (which lists quotes rather than invoices).
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 context by mentioning filtering capabilities ('取引先や期間で絞り込み可能です' - can filter by partner and period), which suggests when this tool might be preferred over unfiltered alternatives. However, it doesn't explicitly state when to use this tool versus siblings like mf_get_billing or mf_list_quotes, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 starting a local server and waiting for callback, which gives some context about the tool's behavior (e.g., it likely involves network operations and user interaction). However, it lacks details on critical aspects such as authentication requirements, potential side effects (e.g., opening a browser), error handling, or rate limits. For a tool with no annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and key behavior. Every sentence earns its place by providing essential information without unnecessary details, making it efficient and well-structured.
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?
Given the tool's complexity (involves OAuth and local server operations), lack of annotations, and no output schema, the description is incomplete. It covers the basic purpose and some behavior but misses important contextual details like what the tool returns, error conditions, or how it integrates with sibling tools. While it's adequate for a minimal understanding, there are clear gaps that could hinder effective use by an AI agent.
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 input schema has 1 parameter with 100% description coverage, so the schema already documents the 'wait' parameter thoroughly. The description doesn't add any meaning beyond what the schema provides regarding parameters. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'OAuth認証を開始します' (starts OAuth authentication) and 'ローカルサーバーを起動してコールバックを待ちます' (starts a local server and waits for callback). It specifies the verb ('開始します' - starts) and resource (OAuth authentication), but doesn't explicitly differentiate from sibling tools like mf_auth_callback or mf_auth_status, which is why it's not a 5.
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 context by mentioning starting a local server and waiting for callback, which suggests this is for initiating OAuth flows. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like mf_auth_callback or mf_auth_status, nor does it specify prerequisites or exclusions. The usage is implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions filtering capabilities but lacks critical details: it doesn't specify if this is a read-only operation, whether it requires authentication, what the return format is (e.g., paginated list), or any rate limits. For a list tool with 7 parameters, this leaves significant gaps in understanding its behavior.
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 front-loads the core purpose and briefly mentions filtering capabilities. There's no wasted text, and it's appropriately sized for a list tool with good schema documentation.
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?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and hints at filtering, but lacks details on authentication, return format, pagination behavior, or error handling. With no output schema, the agent must infer the response structure, making the description incomplete for full contextual understanding.
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?
Schema description coverage is 100%, so the schema fully documents all 7 parameters with descriptions and an enum for 'status'. The description adds minimal value by mentioning partner and date filtering, but doesn't provide additional context beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.
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 verb ('取得します' - retrieve/get) and resource ('見積書一覧' - list of quotes), making the purpose evident. It distinguishes itself from siblings like mf_get_quote (singular) by focusing on listing multiple quotes. However, it doesn't explicitly differentiate from mf_list_billings or other list tools beyond the resource type.
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 for filtering by partner and date range ('取引先や期間で絞り込み可能です'), suggesting when to use it for filtered queries. However, it doesn't provide explicit guidance on when to choose this over alternatives like mf_list_billings or mf_get_quote, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers crucial behavioral information: it explicitly states the tool is non-functional ('機能しません'), explains why (v3 API doesn't support the endpoint), and provides workaround guidance. This goes well beyond what a typical description would cover, addressing operational status and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve distinct purposes: the first states the intended function, the second explains the current limitation and alternative. No wasted words, though the technical detail about v3 API could be slightly more front-loaded for immediate clarity.
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 non-functional status, the description provides complete contextual information: it explains what the tool would do if functional, why it doesn't work, and what to do instead. With no output schema and no annotations, this description adequately covers the essential context an agent needs to understand this tool's special situation.
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?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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: '見積書から納品書を作成します' (creates a delivery slip from a quote). It specifies the resource (delivery slip) and source (quote), but doesn't distinguish from sibling tools like mf_convert_quote_to_billing or mf_create_billing_from_quote beyond mentioning it's for delivery slips specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states the tool is currently non-functional due to v3 API limitations ('このツールは機能しません'), specifies when NOT to use it (for v3 API), and provides an alternative action ('納品書はマネーフォワードのWebUIから作成してください'). This is comprehensive guidance for both usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mf-invoice-mcp MCP server](https://glama.ai/mcp/servers/tera911/mf-invoice-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tera911/mf-invoice-mcp)

Score Badge

Copy to your README.md:

[![mf-invoice-mcp MCP server](https://glama.ai/mcp/servers/tera911/mf-invoice-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tera911/mf-invoice-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/tera911/mf-invoice-mcp'

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