MT Content Refactor MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like connections, backups, content items, and transformations, with clear boundaries. However, mt_set_transform and mt_set_bulk_transform could be slightly confusing as they differ only in scale (individual vs. bulk), but their descriptions clarify this distinction.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a 'mt_' prefix, using clear verb_noun combinations (e.g., mt_add_connection, mt_list_entries). This predictability makes it easy for agents to understand and navigate the toolset.
Tool Count3/5
With 23 tools, the count is on the higher side for a content refactoring server, which may feel heavy but is not extreme. It covers multiple aspects like connections, backups, content management, and transformations, but could potentially be streamlined without losing core functionality.
Completeness5/5
The toolset provides comprehensive coverage for content refactoring workflows, including CRUD operations for connections, backups, and content items, plus transformation and restoration capabilities. No obvious gaps exist; agents can perform full lifecycle tasks from setup to application and rollback.
Average 2.8/5 across 23 of 23 tools scored. Lowest: 1.7/5.
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

Behavior1/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 fails to explain critical aspects: whether this is a read-only or destructive operation, what permissions are required, what happens when changes are applied (e.g., overwriting data, triggering side effects), or any rate limits. The mention of 'dryRun' in the schema hints at a potentially destructive action, but the description doesn't address this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, vague sentence that under-specifies rather than being concise. It lacks front-loaded clarity and fails to convey essential details efficiently, making it unhelpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by applying changes (likely a mutation) and the absence of annotations and output schema, the description is severely incomplete. It doesn't explain what 'MT' is, what transformations are, the impact of the operation, or expected outcomes, leaving the agent with insufficient 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%, with the single parameter 'dryRun' well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '変換結果をMTに適用します' (Applies transformation results to MT) is a tautology that essentially restates the tool name 'mt_apply_changes' without providing meaningful specificity. It doesn't clarify what 'MT' refers to (likely a system or database), what kind of changes are being applied, or how this differs from sibling tools like mt_set_transform or mt_set_bulk_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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., requiring a transformation to be generated first), exclusions, or relationships to sibling tools like mt_set_transform or mt_generate_diff_report, leaving the agent with no context for appropriate tool selection.
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 tool adds a connection but doesn't cover critical behaviors: whether this is a write operation requiring permissions, if it's idempotent, what happens on success/failure, or if there are rate limits. The description is minimal and leaves the agent guessing about behavioral traits beyond the basic action.
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 has zero waste and is appropriately sized for a basic tool, though it could benefit from slightly more detail to improve clarity without losing conciseness. Every word earns its place, but it's borderline under-specified.
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 write operation with 5 required parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what an 'MT connection' is, the expected return values, error conditions, or how it integrates with sibling tools. For a mutation tool with significant context, this minimal description leaves too many gaps 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?
Schema description coverage is 100%, with all 5 parameters well-documented in the input schema (e.g., id, name, endpoint, username, password). The description adds no additional meaning beyond what the schema provides, such as explaining parameter relationships or usage context. Baseline 3 is appropriate since the schema does the heavy lifting, but the description 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 '新しいMT接続を追加します' (Adds a new MT connection) clearly states the action (adds) and resource (MT connection), but it's vague about what an 'MT connection' entails and doesn't distinguish it from sibling tools like mt_test_connection or mt_remove_connection. It provides basic purpose but lacks specificity about the connection's nature or 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or refer to sibling tools like mt_list_connections for viewing connections or mt_remove_connection for deletion. Usage is implied only by the action 'adds,' with no explicit context or exclusions 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'generates a diff report' implies a read-only operation that creates output, it doesn't specify whether this is a heavy computation, whether it requires specific data to be loaded first, what the output format looks like, or if there are any rate limits. The description is too minimal for a tool that presumably processes transformation data.
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 that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. However, the extreme brevity comes at the cost of completeness, making it more under-specified than optimally concise.
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 description that only states the basic purpose, this is incomplete for a tool that presumably processes transformation data. The description doesn't explain what inputs are needed beyond the format parameter, what the diff report contains, or how it relates to the transformation workflow implied by sibling tools. For a tool in what appears to be a content transformation system, more context is needed.
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 the single parameter 'format' fully documented in the schema with enum values and default. The description doesn't add any parameter information beyond what the schema provides. With high schema coverage and only one parameter, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'generates a diff report before and after conversion' which is clear in its verb+resource combination. However, it doesn't distinguish this tool from potential siblings like 'mt_apply_changes' or 'mt_set_transform' which might also involve transformation processes. The purpose is understandable but lacks sibling differentiation.
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. With siblings like 'mt_apply_changes' (which might apply transformations) and 'mt_set_transform' (which might configure transformations), there's no indication whether this tool should be used before, after, or instead of those operations. No usage context 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 full burden for behavioral disclosure. It only states the action ('取得します' - get) without details on permissions, rate limits, pagination behavior (implied by limit/offset but not explained), or what happens on errors. For a list operation with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('記事一覧を取得します') that is front-loaded with the core action. It wastes no words, though it could be more informative. Given the minimal content, it scores well for conciseness but loses a point for under-specification.
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 and no output schema, the description is incomplete for a tool with 4 parameters. It doesn't explain return values, error handling, or behavioral traits like pagination. For a list operation in a context with many sibling tools, more detail is needed to ensure proper 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 schema already documents all parameters (siteId, limit, offset, status) with descriptions. The description adds no additional meaning beyond what's in the schema, such as examples for status beyond the schema's '例: Publish, Draft' or context for siteId. Baseline 3 is appropriate when schema does the heavy lifting.
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 list of articles) states the basic action (get/list) and resource (articles), which provides a vague purpose. However, it doesn't specify what type of articles or distinguish from sibling tools like mt_list_pages or mt_list_content_data, leaving ambiguity about the exact 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. The description doesn't mention prerequisites, context, or exclusions, and with sibling tools like mt_get_entry (for single entries) and mt_list_pages (for pages), there's no indication of when this specific list tool is appropriate.
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 only states it 'gets details', implying a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the output entails. For a tool with no annotations, this is insufficient to inform the agent about 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 with no wasted words. It's front-loaded with the core action, making it easy to parse. Every part of the sentence contributes directly to stating the tool's purpose, earning its place without redundancy.
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 3 required parameters, the description is incomplete. It doesn't explain what 'details' include, how the IDs interrelate, or the return format. For a data retrieval tool in a complex system with many siblings, this leaves significant gaps for the agent to operate 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 input schema has 100% description coverage in Japanese, providing basic parameter meanings. The description adds no additional semantic context beyond implying it fetches details based on IDs. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with extra insights like parameter relationships or usage examples.
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 details of content data) states a clear verb ('取得します' - get) and resource ('コンテンツデータ' - content data), but it's vague about what 'details' means and doesn't distinguish it from similar siblings like 'mt_get_entry' or 'mt_get_page'. It's better than a tautology but lacks specificity.
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, context, or exclusions, and with siblings like 'mt_list_content_data' and 'mt_get_entry', there's no indication of how this differs or when it's appropriate. This leaves the agent without usage direction.
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 only states the action ('取得します' - get) without mentioning permissions, rate limits, response format, or error handling. This is inadequate for a tool that likely interacts with a content management system.
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. It's front-loaded with no wasted words, making it highly concise and well-structured for its minimal content.
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 retrieving entry details (likely from a CMS), no annotations, and no output schema, the description is incomplete. It lacks information on what 'details' include, authentication needs, or potential side effects, leaving significant gaps for an AI agent to use this tool 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 schema description coverage is 100%, with both parameters (siteId and entryId) clearly documented in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 entry details) states a clear verb ('取得します' - get) and resource ('記事の詳細' - entry details), but it's vague about what constitutes 'details' and doesn't distinguish this tool from potential siblings like mt_get_content_data or mt_get_page, which might also retrieve content-related information.
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. Given siblings like mt_list_entries (which likely lists entries) and mt_get_content_data (which might retrieve content data), the description offers no context on use cases, 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. It only states the action ('get list') without mentioning permissions, rate limits, pagination behavior, or response format. This is inadequate for a tool with multiple parameters and no output schema.
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 with zero waste. It's appropriately sized and front-loaded, 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 the tool has 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, leaving significant gaps for the agent to infer.
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 parameters. The description adds no additional meaning beyond what's in the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 content data list) states a clear verb ('取得します' - get) and resource ('コンテンツデータ一覧' - content data list), but it's vague about scope and doesn't distinguish from siblings like 'mt_get_content_data' or 'mt_list_entries'. It provides basic purpose but lacks specificity.
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 on when to use this tool versus alternatives is provided. The description doesn't mention context, prerequisites, or exclusions, leaving the agent with no usage instructions beyond the basic purpose.
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) but does not describe permissions, rate limits, pagination, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding 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 purpose without unnecessary words. It is appropriately sized and front-loaded, with no wasted 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 no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, or how it differs from sibling tools. For a tool with one parameter but no structured context, more information is needed to be fully helpful.
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 the parameter 'siteId' documented in the schema as 'サイトID' (site ID). The description does not add any meaning beyond this, such as explaining what a site ID is or how it affects the output. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 a list of content types) states a clear verb ('取得します' - get) and resource ('コンテンツタイプ一覧' - list of content types), but it does not differentiate from sibling tools like mt_list_entries or mt_list_pages, which also list resources. It is vague about scope or filtering compared to siblings.
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 such as mt_list_entries or mt_list_content_data. The description lacks context about prerequisites, exclusions, or specific use cases, offering only a basic statement of purpose.
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, the description carries the full burden but only states the action without behavioral details. It doesn't disclose what 'test' involves (e.g., whether it performs a ping, checks permissions, or returns status codes), potential side effects, or error handling. This leaves the agent guessing about 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, clear sentence in Japanese, front-loaded with the core action. There's no wasted text, making it highly concise and well-structured for its purpose.
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 and no output schema, the description is incomplete for a tool that likely returns test results (e.g., success/failure, details). It doesn't explain what the tool returns or how to interpret outcomes, leaving gaps in understanding its full context and utility.
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 the parameter 'connectionId' documented as optional and defaulting to the active connection. The description adds no meaning beyond this, as it doesn't mention parameters at all. Baseline 3 is appropriate since the schema adequately covers the single parameter.
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 '接続をテストします' (tests the connection) states the verb and resource, but it's vague about what 'test' entails (e.g., connectivity, authentication, or functionality). It doesn't distinguish from siblings like 'mt_list_connections' or 'mt_use_connection', which involve connections but serve different purposes.
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. For example, it doesn't clarify if this should be used before 'mt_use_connection' to verify connectivity or as a diagnostic step after errors. The description alone offers no context for usage decisions.
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 '削除します' (deletes) implies a destructive mutation, it doesn't specify whether deletion is permanent, requires specific permissions, affects associated data, or what happens on success/failure. For a destructive operation 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 directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, 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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what 'deletion' entails (permanent/soft), error conditions, permissions needed, or what happens to associated backup data. For a tool that permanently removes resources, this level of documentation is inadequate.
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 the single parameter 'sessionId' clearly documented in the schema as 'セッションID' (session ID). The description doesn't add any additional semantic context about the parameter beyond what the schema provides, so it meets the baseline of 3 when 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 ('削除します' - deletes) and the resource ('バックエンドセッション' - backup session), providing a specific verb+resource combination. However, it doesn't distinguish this deletion operation from other deletion-like operations among sibling tools (like mt_remove_connection or mt_restore which might also involve removal).
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's no mention of prerequisites (e.g., needing an existing session), exclusions, or comparisons to sibling tools like mt_list_sessions (to identify sessions) or mt_restore (which might involve session handling).
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 it 'gets' details (implying a read operation), but doesn't disclose whether it's safe, requires authentication, has rate limits, or what the return format looks like. For a read tool with zero annotation coverage, this is inadequate, though not contradictory.
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. It's front-loaded with the core action and resource, with zero wasted words. This is appropriately concise for a simple retrieval tool.
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 2 required parameters, the description is incomplete. It doesn't explain what 'details' are returned, error conditions, or behavioral aspects like idempotency. For a retrieval tool in a content management context, 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 input schema has 100% description coverage (siteId and pageId are documented in Japanese), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain how to obtain siteId/pageId or their formats). It relies entirely on the schema for 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 'ウェブページの詳細を取得します' (Get web page details) clearly states the verb ('取得します' - get/retrieve) and resource ('ウェブページの詳細' - web page details). It distinguishes from siblings like mt_list_pages (which lists pages) and mt_get_content_data (which gets content data). However, it doesn't specify what 'details' include, making it slightly less specific than a perfect 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. It doesn't mention when to use mt_get_page versus mt_list_pages (for listing) or mt_get_entry (for entries), nor does it specify prerequisites like needing siteId and pageId. This leaves the agent without contextual usage instructions.
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), which is safe, but doesn't disclose behavioral traits like pagination behavior (implied by limit/offset but not explained), rate limits, authentication needs, or what happens with invalid inputs. The description is minimal and lacks critical context for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese ('ウェブページ一覧を取得します') that directly states the purpose. It's front-loaded with no wasted words, making it highly concise and well-structured for its minimal content.
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 4 parameters, the description is incomplete. It lacks details on behavior, error handling, return format, or how to interpret results. For a list operation with filtering and pagination, more context is needed to guide 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 schema already documents all parameters (siteId, limit, offset, status) with descriptions. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ウェブページ一覧を取得します' (Get a list of web pages) clearly states the verb ('取得します' - get) and resource ('ウェブページ一覧' - list of web pages). It distinguishes from siblings like mt_get_page (singular) and mt_list_content_data/entries/sites, but doesn't explicitly differentiate from mt_list_content_data which might overlap in domain.
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 on when to use this tool versus alternatives like mt_get_page (for a single page) or mt_list_content_data/entries (for other content types). The description implies usage for listing web pages but lacks explicit 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.
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 a read operation ('取得します'), implying it's likely non-destructive, but doesn't disclose any behavioral traits such as permissions needed, rate limits, pagination, or response format. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 any fluff. It's appropriately sized and front-loaded, with every word earning 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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks context on what 'sites' refer to in this system, how results are returned, or any behavioral nuances, making it inadequate for full understanding despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as there's nothing to compensate for.
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 site list) states a clear verb ('取得します' - get/retrieve) and resource ('サイト一覧' - site list), providing basic purpose. However, it doesn't distinguish from sibling tools like 'mt_list_connections' or 'mt_list_content_types' beyond the resource name, making it somewhat vague about what specifically makes this listing unique.
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. With siblings like 'mt_list_connections' and 'mt_list_content_types', there's no indication of context, prerequisites, or exclusions for selecting this tool over others, leaving usage entirely implicit.
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 loads past backup sessions but doesn't explain what 'load' entails—whether it's read-only, modifies state, requires specific permissions, has side effects, or returns data. For a tool with potential data access implications, this lack of detail 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 purpose. It is front-loaded with no unnecessary words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't clarify the tool's behavior (e.g., read-only vs. mutative), return values, or error conditions. For a tool that likely interacts with backup data, more context is needed to ensure safe and correct usage by an 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, with the single parameter 'sessionId' documented as 'セッションID' (session ID). The description adds no additional meaning beyond this, such as format examples or where to obtain the ID. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles 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 action (読み込みます/load) and resource (バックアップセッション/backup session) in Japanese. It distinguishes from siblings like mt_create_backup, mt_delete_session, and mt_list_sessions by specifying loading of past sessions rather than creating, deleting, or listing them. However, it doesn't explicitly differentiate from mt_restore, which might involve similar functionality.
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 existing session ID), exclusions, or comparisons to siblings like mt_restore or mt_get_backup_items. The agent must infer usage from the name and context 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 without disclosing behavioral traits. It doesn't mention if this is destructive, requires specific permissions, has side effects, or what happens upon deletion (e.g., irreversible changes). More context is needed for a mutation tool.
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 action. It's front-loaded with no wasted words, making it highly concise and well-structured for its purpose.
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 as a destructive operation with no annotations and no output schema, the description is incomplete. It lacks details on behavior, outcomes, or error handling, which are crucial for safe invocation. More information is needed to compensate for the missing structured data.
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?
Schema description coverage is 100%, with the parameter 'connectionId' clearly documented in the schema as '削除する接続のID' (ID of the connection to delete). The description doesn't add extra meaning beyond the schema, but with only one parameter and high coverage, a baseline of 4 is appropriate as it's minimally sufficient.
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 '接続を削除します' (removes a connection) states a clear verb+resource action, but it doesn't differentiate from sibling tools like 'mt_delete_session' or specify what type of connection is being removed. It's vague about the resource scope compared to 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?
No guidance is provided on when to use this tool versus alternatives like 'mt_delete_session' or 'mt_list_connections'. The description lacks context about prerequisites, such as needing an existing connection ID, or exclusions, leaving the agent without usage direction.
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 ('restore') but doesn't mention whether this is destructive (e.g., overwrites current state), requires specific permissions, has side effects, or what the response entails. This is a significant gap for a mutation tool.
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 wasted words. It is appropriately sized and front-loaded, 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 a restore operation (likely a mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like destructiveness, error handling, or return values, leaving critical gaps for the agent to understand the tool fully.
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%, so the input schema fully documents the single parameter 'sessionId'. The description adds no additional parameter information beyond what's in the schema, resulting in a baseline score of 3 as the schema handles 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 ('restore') and the target ('from backup to original state'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'mt_create_backup' or 'mt_load_session', but the verb 'restore' implies a distinct operation from creation or loading, so it's clear but not fully differentiated.
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 'mt_load_session' or 'mt_apply_changes'. The description lacks context about prerequisites, such as needing a backup created first, or exclusions, leaving the agent with no usage instructions.
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. While 'sets' implies a write/mutation operation, it doesn't specify whether this requires special permissions, whether changes are reversible, what happens on partial failures, or any rate limits. The bulk nature suggests potential performance implications that aren't addressed.
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 any unnecessary words. It's perfectly front-loaded and 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?
For a mutation tool ('sets') with no annotations and no output schema, the description is insufficient. It doesn't explain what 'transformed HTML' means, what format the transforms array should contain, what happens after setting, or any error conditions. The bulk operation aspect adds complexity that isn't addressed.
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 the single parameter 'transforms' documented as 'array of transformation results'. The description adds no additional parameter context beyond what the schema already provides, so 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 ('sets transformed HTML in bulk') and the target ('multiple items'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'mt_set_transform' (which appears to be a single-item version), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mt_set_transform' (presumably for single items) or other content modification tools. There's no mention of prerequisites, timing considerations, or exclusion criteria.
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 that the tool 'sets' transformed HTML, implying a write/mutation operation, but doesn't clarify whether this is destructive, requires specific permissions, or has side effects (e.g., overwriting existing HTML, triggering updates). It also doesn't describe the response format or error conditions, which is a significant gap for a mutation tool.
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 action and target, making it easy to parse. Every part of the sentence contributes to understanding the purpose, with no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (setting HTML on items) with no annotations and no output schema, the description is incomplete. It doesn't address key contextual aspects like what 'transformed' implies, how this interacts with other tools (e.g., 'mt_apply_changes'), or what happens after setting the HTML. For a tool that likely modifies content in a system, more detail on behavior and integration is needed.
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 documented in the schema (itemType, itemId, afterHtml). The description adds no additional semantic context beyond what's in the schema—it doesn't explain what 'transformed HTML' means, how itemType relates to the itemId, or provide examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate with any extra insights.
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 ('設定します' - sets) and the target ('変換後のHTML' - transformed HTML) on individual items. It distinguishes from the sibling tool 'mt_set_bulk_transform' by specifying '個別のアイテム' (individual items), though it doesn't explicitly name the alternative. The purpose is specific but could be more precise about what 'transform' means in this 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 like 'mt_set_bulk_transform' for bulk operations, or when to use it in relation to other tools such as 'mt_apply_changes' or 'mt_generate_diff_report'. It doesn't mention prerequisites, dependencies, or typical workflows, leaving the agent to 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 for behavioral disclosure. It states the action ('activates') but doesn't explain what 'activates' entails—whether it changes system state, requires permissions, has side effects, or what happens upon success/failure. This leaves significant gaps for a mutation tool.
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 action without unnecessary words. It's appropriately sized and front-loaded, earning its place clearly.
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 mutation operation with no annotations and no output schema), the description is insufficient. It doesn't cover what 'activates' means behaviorally, what the expected outcome is, or how it integrates with other connection tools, leaving the agent with incomplete context.
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 the single parameter 'connectionId' documented as '使用する接続のID' (ID of the connection to use). The description adds no additional meaning beyond this, so it meets the baseline of 3 where 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 '指定した接続をアクティブにします' (Activates the specified connection) clearly states the verb ('activates') and resource ('connection'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'mt_list_connections' or 'mt_test_connection', which prevents a score of 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 sibling tools related to connections (add, list, test, remove), but no indication of prerequisites, typical workflows, or when this activation is needed versus other connection operations.
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. The description only states what the tool does ('displays a list') without mentioning behavioral traits such as whether it's read-only (implied but not explicit), whether it requires authentication, if there are rate limits, pagination behavior, or what format the output takes. For a 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 directly states the tool's purpose with zero waste. It's appropriately sized for a simple listing tool and front-loaded with the essential information. Every word earns its place, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states the basic purpose but lacks context about output format, behavioral constraints, or usage guidelines. For a simple read operation, this might be adequate, but it doesn't provide enough information for an agent to fully understand how to use it effectively, especially without annotations.
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% (though empty). With no parameters, the description doesn't need to add semantic details beyond what the schema provides. The baseline for 0 parameters is 4, as there's nothing to compensate for, and the description appropriately doesn't discuss parameters.
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 'バックアップセッション一覧を表示します' (Displays a list of backup sessions) states a clear verb ('表示します' - displays) and resource ('バックアップセッション一覧' - backup session list). However, it doesn't distinguish this tool from its siblings like 'mt_list_connections', 'mt_list_content_data', or 'mt_list_pages', which all follow the same 'list' pattern for different resources. The purpose is clear but lacks sibling differentiation.
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 backup sessions must exist), when this tool is appropriate compared to other listing tools, or any exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
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 displays a list, implying a read-only operation, but doesn't specify details like whether it requires authentication, how results are formatted (e.g., pagination, sorting), or if there are rate limits. 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 that directly states the tool's purpose without any fluff. It's front-loaded with the core functionality and wastes no words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. For a basic list tool, this might suffice, but it doesn't provide enough depth for more complex scenarios, such as understanding result limitations or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it naturally meets the baseline. It doesn't introduce any parameter-related information, which is appropriate given the lack of parameters.
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: 'バックアップしたアイテムの一覧を表示します' translates to 'Displays a list of backed-up items.' This specifies the verb ('displays') and resource ('backed-up items'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'mt_list_content_data' or 'mt_list_entries,' which might also list items in different contexts, so it falls short of 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, such as whether backups must exist first, or compare it to siblings like 'mt_list_sessions' or 'mt_list_sites' that might list other resources. Without any context or exclusions, users are left to infer usage based on the tool name 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. It states the tool displays a list, implying it is a read-only operation, but does not specify details like whether the list is paginated, sorted, or includes all connections. For a tool with zero annotation coverage, this is a significant gap in transparency about how the tool behaves.
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 any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context. For a simple list tool, this might be sufficient, but it does not provide complete guidance for an agent to use it effectively in all scenarios.
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 the schema description coverage is 100%, meaning there are no parameters to document. The description does not need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description does not mislead about parameters, but it does not explicitly state 'no parameters required,' which could slightly improve clarity.
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: '登録済みのMT接続一覧を表示します' translates to 'Displays a list of registered MT connections.' This specifies the verb ('displays') and resource ('registered MT connections'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'mt_get_entry' or 'mt_list_sites,' which prevents a score of 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. It does not mention any prerequisites, such as needing existing connections to list, or suggest when to use it over other listing tools like 'mt_list_sessions' or 'mt_list_sites.' This lack of context leaves the agent without usage direction.
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 the tool creates backups and should be used before conversion, but lacks details on permissions needed, whether it's destructive (e.g., overwrites existing backups), rate limits, or what the backup process entails (e.g., creates files, stores in database). For a backup 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 two concise sentences in Japanese, front-loaded with the core purpose and followed by usage guidance. Every word earns its place with no redundancy or fluff.
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 no annotations and no output schema, the description is minimal but covers the essential purpose and timing. However, for a backup tool that likely involves significant system interaction, it lacks details on behavioral traits, error handling, or output expectations, leaving gaps in 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 (siteId, targetType, status). The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the implications of targetType choices or status filtering. Baseline 3 is appropriate when schema handles 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: 'サイトのコンテンツをバックアップします' (backs up site content). It specifies the resource (site content) and action (backup), though it doesn't explicitly differentiate from sibling tools like 'mt_get_backup_items' or 'mt_restore' beyond the backup creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: '変換前に必ず実行してください' (must be executed before conversion). This indicates when to use the tool (before conversion operations), though it doesn't specify alternatives or exclusions relative to other backup-related tools.
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:

[![mt-content-refactor-mcp MCP server](https://glama.ai/mcp/servers/bit-part/mt-content-refactor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bit-part/mt-content-refactor-mcp)

Score Badge

Copy to your README.md:

[![mt-content-refactor-mcp MCP server](https://glama.ai/mcp/servers/bit-part/mt-content-refactor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bit-part/mt-content-refactor-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/bit-part/mt-content-refactor-mcp'

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