wasurenagusa-mcp

Server Quality Checklist

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

Latest release: v0.15.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between memory_get_context and memory_get_detail, as both retrieve memory information. However, memory_get_context focuses on config and dont categories specifically, while memory_get_detail retrieves full details for any memory entry, which helps differentiate them. The other tools like memory_search, memory_save, and task-related tools are clearly distinct in their functions.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout, such as memory_delete, memory_get_context, and task_submit. All tools use snake_case, which is uniform. The only minor deviation is project_init, which fits the pattern but stands out slightly as it doesn't start with a memory or task prefix, though it's still consistent in structure.
Tool Count5/5
With 10 tools, the count is well-scoped for the server's purpose, which appears to be memory management and task automation. This number allows for comprehensive coverage without being overwhelming, including operations for memory CRUD, context retrieval, and task lifecycle management, making it efficient for agents to handle.
Completeness4/5
The tool set provides good coverage for memory operations (save, search, get, delete, update) and task management (init, action list, status, submit), but there are minor gaps. For example, there's no tool for updating memory content beyond intensity, and task operations lack direct update or delete functions, though agents might work around this with existing tools like task_action_list for resolution.
Average 4.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 82 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

Behavior3/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 adds valuable context about pagination (20-item limit) and specific status taxonomy, but does not explicitly state safety characteristics (read-only nature) or error handling, leaving gaps an annotation would normally cover.
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, dense sentence that front-loads the core function (returning status summaries) and efficiently packs in specific status values and result limits with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately compensates by detailing the return structure (count metrics + task list). For a single-parameter read operation, this provides sufficient completeness, though explicit safety confirmation would strengthen it further.
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%, documenting the optional 'project' filter parameter fully. The description does not mention the parameter, but since the schema is self-explanatory, it meets the baseline expectation without adding redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a status summary (状態サマリ) of autonomous tasks, specifying exact status categories (pending/in-progress/completed/failed/human-required/cancelled) and output format (counts + recent 20 items), effectively distinguishing it from sibling tools like task_submit (submission) and task_action_list (action listing).
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?
While the description implies usage context by detailing the output (status counts and recent tasks), suggesting it's for status overview/monitoring, it lacks explicit guidance on when to use this versus task_action_list or task_submit, and contains no 'when-not-to-use' exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool registers project metadata and saves meta-information, and mentions the autonomous execution context. However, it fails to specify critical operational details: whether 'save' mode is destructive (overwrites existing), idempotent, requires specific file permissions for projectPath, or what side effects occur (file creation vs database storage).
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 efficiently structured with a clear purpose statement followed by operation mode bullets. Every sentence serves a function: the first defines the action and target, the second explains the 'why' (autonomous execution), and the bullets clarify the mode parameter semantics. No redundancy or filler text.
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 (5 parameters, nested objects, conditional requirements, two distinct operating modes) and lack of output schema, the description adequately explains the input workflow but omits critical details about return values (what does 'generate' return? what does 'save' return?) and error conditions. For an initialization tool, it should also address idempotency concerns.
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?
While the schema has 100% coverage documenting each parameter, the description adds valuable workflow context explaining that 'generate' produces questions and 'save' consumes those answers to create metadata. It clarifies the semantic relationship between the mode, answers, and initialInfo parameters beyond the schema's standalone descriptions, though it doesn't add syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'initial project setup' (プロジェクトの初期設定を行う) and specifies exactly what gets registered: 'quality standards, phases, and decision criteria for autonomous task execution' (品質基準・フェーズ・判断基準を登録する). It effectively distinguishes from siblings like memory_* (memory management) and task_* (task execution) by focusing on project metadata initialization.
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 explains the two-mode workflow (generate vs save) and implies the sequence (generate questions first, then save based on answers). However, it lacks explicit guidance on when to use this versus task_submit or memory_save, and doesn't specify prerequisites or conditions where this tool should not be used (e.g., existing projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 successfully explains the semantics of actions (retry=re-execute, complete=manual resolution, cancel=no action needed) and conditional requirements, but lacks disclosure of side effects, return values, or safety profile (e.g., whether resolve operations are reversible).
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 optimally structured with a clear purpose statement followed by an 'Operation modes' section that efficiently delineates the two modes and their associated actions. Every sentence earns its place with zero redundancy.
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 absence of an output schema and annotations, the description adequately covers the input parameters and operational modes but fails to describe what the 'list' mode returns or the success/failure behavior of the 'resolve' mode, leaving gaps in contextual completeness for a tool handling task lifecycle operations.
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?
While the schema has 100% coverage, the description adds significant value by explaining the operational semantics of enum values (e.g., clarifying that 'complete' means manually resolved and 'cancel' means no action needed) and explicitly noting conditional requirements for taskId and action that are not enforced in the schema's required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages 'human action lists' specifically for 'tasks AI could not resolve' (AIが解決できなかったタスク), using specific verbs (管理する, 一覧表示, 対応操作). This effectively distinguishes it from siblings like task_submit (new tasks) and task_status (monitoring).
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?
Provides clear operational guidance through the two-mode structure (list vs resolve) and explains when each parameter is required (mode=resolve時に必須). However, it does not explicitly contrast with sibling tools like task_submit to clarify when to escalate to human action versus initial submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It mentions cross-category deletion scope and bulk capability, but fails to mention whether deletion is permanent, if there are permission requirements, or error handling behavior when IDs don't exist.
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?
Four compact sentences with zero waste: action definition, ID source requirement, bulk capability, and scope flexibility. Information is front-loaded with the core action first, followed by constraints and capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool without output schema, the description adequately covers the operational workflow (search-then-delete) and key behavioral constraints (bulk, cross-category). Minor gap in not describing the operation's result or permanent nature, but sufficient for correct invocation.
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?
While the schema has 100% coverage (baseline 3), the description adds valuable semantic context by specifying that IDs come from 'memory_search' (workflow prerequisite) and explicitly noting that multiple IDs can be bulk-specified, reinforcing the array nature of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'メモリエントリを削除する' (Delete memory entries), providing a specific verb and resource. It clearly distinguishes this as the sole deletion tool among siblings (memory_save, memory_search, memory_update_intensity, etc.).
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 workflow guidance by specifying that IDs should be obtained from 'memory_search' first. It also notes bulk and cross-category deletion capabilities. However, it lacks explicit 'when not to use' guidance or mention of alternatives like memory_update_intensity for partial modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses batch capability ('複数IDを一括指定可能') and cost implications (token saving). However, lacks disclosure of error behavior (what happens if ID not found), idempotency, or safety characteristics beyond the implicit 'get' operation.
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?
Extremely concise with two efficient sentences. First sentence establishes purpose and batch capability; second provides optimization guidance. Zero redundancy, front-loaded with essential workflow information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects, 100% schema coverage), the description is appropriately complete. It explains the integration with memory_search (sibling tool) and batch behavior. Minor gap regarding error handling or return value description, but acceptable without output schema.
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 coverage is 100%, establishing baseline 3. Description adds valuable semantic context that IDs should come specifically from memory_search (not arbitrary sources) and emphasizes batch retrieval capability, enriching the 'ids' parameter meaning beyond the schema's basic type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves 'full details' (フル詳細) of memories using IDs, with specific verb+resource. It distinguishes from sibling memory_search by explicitly stating this tool requires IDs obtained from memory_search, establishing a clear workflow dependency.
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?
Provides explicit prerequisite ('memory_search で取得したIDを指定して'), guiding users to search first. Includes specific optimization guidance ('必要なものだけ取得してトークンを節約') for efficient usage. Lacks explicit 'when not to use' or named alternatives, though the workflow implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses behavioral semantics of the intensity parameter (the 1-10 scale meaning from '提案' to '激怒') and category taxonomy, but omits operational details like idempotency, overwrite behavior for duplicate titles, or error conditions.
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?
Perfectly structured with the core action front-loaded, followed by a scannable bulleted category list with inline semantics, and closing with specific title guidance. No redundant text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and lack of output schema, the description is appropriately complete for a save operation. It comprehensively covers the categorical taxonomy and intensity semantics that the schema cannot express fully, though it could briefly mention whether the operation returns an ID or confirmation.
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?
While the input schema has 100% description coverage (baseline 3), the description adds significant semantic value by detailing what each enum value in 'category' represents (e.g., 'config: API URL、ポート、認証情報などの設定') and expanding the 'intensity' parameter with the full semantic scale of anger levels (1=提案 through 5=激怒).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb+resource 'メモリを保存する' (save memory) and immediately distinguishes this as the creation tool among CRUD siblings by enumerating the five distinct category types (config, dont, decision, log, snippet) that can be saved.
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?
Provides extensive contextual guidance on when to use each category (e.g., 'config' for API URLs/auth, 'dont' for past mistakes, 'snippet' for commands) and specific title formatting instructions. Lacks explicit comparison to sibling tools like memory_update_intensity or memory_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 successfully conveys the SessionStart Hook injection pattern, which is critical operational context. However, it lacks explicit statements about read-only safety, idempotency, caching behavior, or the structure of the returned config/dont data, leaving gaps in the safety/behavioral profile.
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?
Three sentences with zero waste: (1) function definition, (2) automatic usage pattern/warning, (3) exceptional manual usage case. The logical flow moves from what it does, to the common case (don't use), to the edge case (do use). Japanese text is economical and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description adequately covers the operational context (hook injection) and identifies the returned data categories (config and dont). However, given the absence of annotations and output schema, it could be improved by explicitly confirming the read-only nature of the operation or describing the return format structure.
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 contains zero parameters (empty object). According to calibration rules, zero parameters establishes a baseline score of 4. The description correctly does not invent parameter documentation where none exist, and the 100% schema coverage is vacuously satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs batch retrieval ('一括取得') of specific resources: 'config' (configuration) and 'dont' (constraints/things not to do). It clarifies what 'context' means in this domain, effectively distinguishing it from siblings like memory_get_detail or memory_search which likely operate on specific memories rather than system context.
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?
Provides explicit usage guidance: it states when NOT to use the tool ('通常はSessionStart Hookで自動注入されるため、手動で呼ぶ必要は少ない' - rarely needed manually because it's auto-injected at session start) and specifically when TO use it ('セッション途中でコンテキストを再確認したい場合' - when reconfirming context mid-session). This clear conditional guidance prevents unnecessary invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral trait that only partial data is returned (軽量インデックスのみ), explains the token-saving optimization strategy, and clarifies the return structure. Minor gap: doesn't specify behavior when no matches found.
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?
Three sentences with zero waste: (1) purpose declaration, (2) critical limitation + alternative tool, (3) optimization rationale. Front-loaded with 【重要】alert and efficient Japanese prose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong coverage for a 5-parameter search tool with no output schema: explains return format (lightweight index), workflow integration with memory_get_detail, and cost optimization. Lacks only error-handling context (e.g., empty results behavior) to be perfect.
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% (all 5 parameters fully documented), so baseline score applies. Description focuses on behavioral guidance rather than repeating parameter details already covered in schema, which is appropriate prioritization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource (メモリを検索する) and immediately distinguishes from sibling tools by clarifying it returns only lightweight index (ID, title, tags) rather than full content, explicitly naming memory_get_detail as the alternative for full data.
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?
Provides explicit when-not-to-use guidance (フル内容が必要な場合は...memory_get_detailに渡すこと) and describes the two-step workflow (search IDs first, fetch details selectively) to optimize token usage, directly addressing the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses critical behavioral details: setting intensity 6+ results in 'highest priority in context injection' (context注入で最優先される), explaining the ranking mechanism. It also clarifies this is a partial update (only intensity). It does not mention error handling for invalid IDs or idempotency, but covers the key domain-specific 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?
Three tightly structured sentences with zero waste: (1) purpose/scope, (2) usage mechanics and threshold behavior, (3) prerequisite workflow. Information is front-loaded and every sentence earns its place. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple 2-parameter update tool. It explains the domain concept (intensity/pinning), references the necessary sibling tool (memory_search) for the workflow, and describes the priority system's effect. No output schema exists, but the description does not need to explain return values for this type of operation.
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 coverage is 100%, establishing a baseline of 3. The description adds workflow semantics beyond the schema: it specifies that the ID should come from memory_search (establishing tool chaining) and elaborates on the 'context injection priority' effect of the intensity parameter, which is not fully explained in the schema's description of the number range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'only changes the intensity of existing memory entries' (既存メモリエントリのintensityだけを変更する), using a specific verb and resource. It explicitly distinguishes itself from creation tools like memory_save by emphasizing 'existing' entries and narrowing scope to 'only intensity'.
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?
Provides clear context for when to use: 'Used for pin operation' (ピン留め運用に使う) and specifies the prerequisite workflow 'Specify the ID obtained from memory_search' (memory_searchで取得したIDを指定すること). However, it does not explicitly state when NOT to use it (e.g., for creating new entries) or name alternatives like memory_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: continuous execution (24/365), automatic retry logic, and completion-based termination. It could be strengthened by mentioning failure modes (e.g., max retry limits) or return values, but the execution model disclosure is substantial.
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?
Extremely efficient structure: one sentence for purpose/behavior, a header '投入する4項目:', then four bullet-style parameter definitions. Every line earns its place. The critical behavioral information (24/365, retry) is front-loaded before parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter flat schema with no output schema, the description adequately covers operational context. It explains what happens after invocation (AI takes over execution). Minor gap: doesn't describe the return value (likely a task ID) or how to reference the task later, though sibling tools suggest this functionality exists.
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 coverage is 100%, establishing a baseline of 3. The description adds significant value by providing a concrete, syntax-rich example for the 'done' parameter: '例: "npx tsc通過 + vitest全パス"'. This example clarifies expected machine-verifiable formats beyond the schema's abstract description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '自律タスクを投入する' (submit autonomous tasks) and immediately clarifies the unique execution model: 'AIが24/365で自動実行し、完了条件を満たすまでリトライする' (AI executes automatically 24/365, retrying until completion conditions are met). This specific verb+resource+behavioral scope clearly distinguishes it from siblings like task_status (query) or memory_save (storage).
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 24/365 auto-execution and retry behavior implicitly signals when to use this (for persistent background tasks) versus one-shot operations. While it doesn't explicitly name alternatives like 'use task_status to monitor progress,' the operational model is distinct enough to guide selection. Lacks explicit 'when not to use' guidance.
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:

[![wasurenagusa-mcp MCP server](https://glama.ai/mcp/servers/tsutushi0628/wasurenagusa-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tsutushi0628/wasurenagusa-mcp)

Score Badge

Copy to your README.md:

[![wasurenagusa-mcp MCP server](https://glama.ai/mcp/servers/tsutushi0628/wasurenagusa-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tsutushi0628/wasurenagusa-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/tsutushi0628/wasurenagusa-mcp'

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