note.com MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, such as 'get-note' for article details versus 'get-user-notes' for user articles. However, some overlap exists, like 'search-notes' and 'search-all' which might cause confusion, and 'get-membership-notes' versus 'get-test-membership-notes' are similar but differentiated by test data. Overall, descriptions help clarify boundaries, but minor ambiguities remain.
Naming Consistency4/5
The tools follow a consistent kebab-case pattern throughout, with clear verb-noun structures like 'get-note', 'post-comment', and 'search-users'. There are minor deviations, such as 'analyze-notes' using a verb that doesn't align with the common 'get' or 'list' patterns, and 'open-note-editor' being more specific. The naming is mostly predictable and readable, supporting easy identification.
Tool Count3/5
With 33 tools, the count is borderline high for a note-taking or content platform server, as it includes many specific retrieval and search functions. While the scope covers articles, users, magazines, and memberships comprehensively, the number feels heavy and could overwhelm agents. It's reasonable but leans toward being over-scoped, especially with test tools that might not be necessary in production.
Completeness5/5
The tool set provides complete coverage for the note.com domain, including CRUD operations for articles (e.g., 'post-draft-note', 'get-note'), social interactions ('like-note', 'post-comment'), and management features for magazines, memberships, and categories. There are no obvious gaps; agents can perform full workflows from creation to analysis and interaction without dead ends.
Average 2.9/5 across 33 of 33 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('取得する' - get) without disclosing behavioral traits such as read-only status, authentication needs, rate limits, or what 'circle information' entails. This is inadequate for a tool with zero annotation coverage, as it lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, which is concise but under-specified. It's front-loaded but lacks necessary detail, making it inefficient rather than truly concise. Every word earns its place, but the place is too small to be helpful, bordering on tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what 'circle information' returns or how it fits into the context of sibling tools. For a read operation, more behavioral and output context is needed to be complete, even with minimal 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 param info, which is fine here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs without requiring description compensation.
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 'サークル情報を取得する' (Get circle information) restates the tool name 'get-circle-info' in Japanese, making it a tautology. It doesn't specify what 'circle information' includes or how it differs from sibling tools like 'get-user' or 'get-stats'. The purpose is vague beyond the literal translation of the name.
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?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'get-user', 'get-stats', and 'search-users', there's no indication of context, prerequisites, or exclusions. The description offers no usage instructions, leaving the agent to guess based on the 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions analysis but doesn't describe what the analysis returns (summary statistics, insights, comparisons), whether it's computationally intensive, if there are rate limits, or what permissions might be required. The description is too vague about the actual behavior of the tool.
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 Japanese sentence that states the core purpose. It's appropriately concise without being overly brief, though it could potentially be more structured by separating different analysis types or adding a brief example.
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 complex analysis tool with 9 parameters and no output schema, the description is insufficient. It doesn't explain what the analysis output looks like (structured data, insights, comparisons), what 'detailed analysis' entails, or how the various parameters affect the analysis results. The agent would struggle to understand what to expect from this tool.
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 9 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'detailed analysis of notes (competitive analysis, content performance comparison, etc.)', which provides a general purpose. However, it doesn't specify what type of analysis is performed (statistical, qualitative, etc.) or how it differs from sibling tools like 'search-notes' or 'get-stats'. The purpose is clear but lacks specificity about the analysis methodology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling tools that retrieve notes (search-notes, get-my-notes, get-user-notes, etc.), the description doesn't explain why an agent would choose this analysis tool over those retrieval tools or when analysis is preferable to simple searching.
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 '取得する' (get) implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the '詳細情報' (detailed information) includes. For a read tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 verbiage or unnecessary elaboration. However, the brevity comes at the cost of completeness, as it omits important contextual information that would help an agent use the tool effectively.
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 read operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what '詳細情報' (detailed information) includes, whether authentication is required, or how this differs from similar retrieval tools. Given the complexity of having multiple magazine/note-related sibling tools and the lack of structured output documentation, the description should provide more context about what this specific tool returns and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters at all, but the input schema has 100% description coverage with a clear parameter description for 'magazineId'. Since schema coverage is high (>80%), the baseline score is 3. The description adds no parameter semantics beyond what the schema already provides, but doesn't need to compensate for poor schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'マガジンの詳細情報を取得する' (Get detailed information of a magazine) clearly states the verb ('取得する' - get) and resource ('マガジン' - magazine), making the purpose understandable. However, it doesn't differentiate from similar sibling tools like 'search-magazines' or 'get-category-notes', leaving ambiguity about when this specific retrieval tool should be used versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search-magazines' and 'get-category-notes' available, there's no indication whether this is for retrieving a specific magazine by ID while others handle searches or category-based retrieval. The description lacks any 'when-to-use' or 'when-not-to-use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('search magazines') without mentioning pagination behavior (implied by 'size' and 'start' parameters), rate limits, authentication needs, or what the search returns. For a search tool with no annotation coverage, this leaves critical behavioral traits unspecified.
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 phrase ('マガジンを検索する') that directly states the tool's purpose. It's appropriately sized and front-loaded with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool with 3 parameters. It doesn't explain what the search returns (e.g., list of magazines, metadata), how results are ordered, or error conditions. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
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 clear documentation for 'query', 'size', and 'start' parameters. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'マガジンを検索する' (Search magazines) states the basic verb and resource, making the purpose understandable. However, it doesn't distinguish this tool from sibling search tools like 'search-all', 'search-notes', or 'search-users', leaving ambiguity about what specifically is being searched. It's 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. With multiple search-related siblings (search-all, search-notes, search-users), there's no indication of scope, context, or exclusions. The agent must infer usage from the name alone, which is insufficient.
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 only states the action ('search notes') without disclosing behavioral traits like pagination, rate limits, authentication needs, or what the search encompasses (e.g., public vs. private notes). This leaves significant gaps for a tool with multiple 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 ('記事を検索する'), with zero wasted words. It's appropriately sized and front-loaded, though its brevity contributes to gaps in other dimensions.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on search behavior, result format, and differentiation from siblings, making it inadequate for effective agent use without additional 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%, so the schema fully documents all parameters. The description adds no meaning beyond what the schema provides (e.g., it doesn't explain search syntax or result format), meeting the baseline of 3 for high schema coverage.
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 '記事を検索する' (Search notes) states the basic verb+resource but is vague about scope and differentiation. It doesn't specify what type of notes are being searched or how this differs from sibling tools like 'search-all', 'search-magazines', or 'search-users', leaving the purpose unclear beyond the generic action.
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. With multiple search-related siblings (e.g., 'search-all', 'search-magazines', 'search-users'), the description lacks any context, prerequisites, or exclusions, offering no help in 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action ('search users') without any information about permissions, rate limits, pagination behavior, or what the search returns. For a search tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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 phrase ('ユーザーを検索する') that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly. Every element earns its place by conveying the core action.
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 search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns, how results are structured, or any behavioral aspects like pagination or error handling. For a tool with three parameters and multiple sibling search tools, 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%, with clear descriptions for 'query' (search keyword), 'size' (number of items to retrieve, max 20), and 'start' (starting position). The description adds no additional meaning beyond what the schema provides, such as search syntax or result format. With high schema coverage, 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 'ユーザーを検索する' (search users) clearly states the verb and resource, making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search-all', 'search-magazines', or 'search-notes', which all perform search operations on different resources. The description is vague about scope or 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. There are multiple search-related sibling tools (e.g., 'search-all', 'search-magazines', 'search-notes'), but the description doesn't indicate that this is specifically for searching users or when it might be preferred over broader search tools. No 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 the full burden of behavioral disclosure. The description only states the action ('取得する' - get) without detailing behavioral traits such as whether this is a read-only operation, if it requires authentication, any rate limits, what the return format might be (e.g., counts as numbers, with timestamps), or potential side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('通知件数を取得する') that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action, making it easy to parse. However, it could be slightly more informative (e.g., specifying the type of notices) to improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with 0 parameters) but lack of annotations and no output schema, the description is incomplete. It does not explain what 'notice counts' entail, the return format, or any behavioral context. While the schema coverage is high, the description fails to provide sufficient context for an AI agent to understand the tool's full behavior and output, especially without annotations to fill in gaps.
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% description coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since none exist. According to the rules, for 0 parameters, the baseline score is 4, as there is no need to compensate for missing parameter information. The description aligns with the schema's lack of 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 '通知件数を取得する' (Get notice counts) states the tool's purpose with a clear verb ('取得する' - get) and resource ('通知件数' - notice counts). However, it lacks specificity about what 'notice counts' refers to (e.g., unread notices, total notices, by category) and does not distinguish this tool from potential sibling tools like 'get-stats' or 'get-search-history', which might also retrieve counts or statistics. The purpose is understandable but vague in 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, and with sibling tools like 'get-stats' and 'get-search-history' that might overlap in retrieving statistical data, there is no indication of how this tool differs or when it is the appropriate choice. Usage is implied only by the name and description, with no explicit 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 full burden. It implies a mutation action ('like'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, idempotency, or what happens on success/failure (e.g., does it increment a like count, return confirmation, or have side effects?). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('記事にスキをする') that directly states the action. It's front-loaded with no wasted words, though it could be more specific to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (liking a note) with no annotations and no output schema, the description is incomplete. It lacks details on authentication, error handling, return values, or how it interacts with sibling tools (e.g., 'unlike-note', 'get-likes'), making it insufficient for reliable agent use.
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 schema description coverage is 100%, with the single parameter 'noteId' clearly documented in the schema as '記事ID' (note ID). The description doesn't add any parameter details beyond this, but with 0 parameters needing extra explanation and high schema coverage, a baseline of 4 is appropriate as no compensation is required.
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 '記事にスキをする' (like a note) states a verb ('like') and resource ('note'), but it's vague about what 'like' means in this context (e.g., adding a like/reaction, bookmarking, or favoriting). It doesn't distinguish from sibling tools like 'unlike-note' or 'get-likes', leaving ambiguity in 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. For example, it doesn't specify prerequisites (e.g., needing authentication or a valid note ID), when to prefer 'like-note' over 'get-likes' for checking likes, or how it relates to 'unlike-note'. This leaves the agent without context for 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. It states the action ('削除する' - remove/delete) but lacks critical behavioral details: whether the deletion is permanent or reversible, if it requires specific permissions, what happens to associated data (e.g., comments or likes), error conditions, or response format. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese ('マガジンから記事を削除する') with zero wasted words. It is front-loaded with the core action, making it easy to parse, though its brevity contributes to gaps in other dimensions.
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 deletion operation with 2 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It states the purpose but misses usage guidelines, parameter details, behavioral traits, and output information, leaving the agent with insufficient context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters at all. It mentions 'magazine' and 'article' but doesn't clarify what 'magazineId' and 'noteId' represent (e.g., IDs, names, or how to obtain them), their formats, or constraints. With two required parameters and no schema descriptions, the description fails to compensate for the coverage gap.
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 'マガジンから記事を削除する' (Remove article from magazine) clearly states the verb ('削除する' - remove/delete) and resource ('記事' - article) with context ('マガジンから' - from magazine). It distinguishes from siblings like 'add-magazine-note' (add) and 'get-magazine' (retrieve), but doesn't specify what type of article or deletion occurs (e.g., permanent vs. soft).
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies deletion from a magazine, but it doesn't mention prerequisites (e.g., needing magazineId and noteId), exclusions (e.g., not for removing comments or likes), or comparisons to siblings like 'unlike-note' or 'post-draft-note' for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write/mutation operation ('add'), but doesn't disclose permissions needed, side effects (e.g., whether the note becomes publicly visible), error conditions, or response format. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence in Japanese, front-loaded with the core action. No wasted words or redundant information. Perfectly sized for the simple operation described.
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?
Incomplete for a mutation tool with no annotations and no output schema. The description doesn't explain what happens after adding (success response, error cases), nor does it clarify the relationship between magazine and note (e.g., ordering, visibility). Given the complexity of adding content to a collection, 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 both parameters clearly documented in the schema (magazineId and noteId as string IDs). The description adds no additional parameter context beyond implying these IDs reference existing resources. Baseline 3 is appropriate 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 'マガジンに記事を追加する' (Add an article to a magazine) clearly states the action (add/append) and target resource (magazine). It distinguishes from siblings like 'remove-magazine-note' (opposite action) and 'get-magazine' (read-only). However, it doesn't specify what type of 'note' is being added (e.g., existing note vs. new content), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing magazine and note IDs), exclusions, or compare with similar tools like 'post-draft-note' (which might create notes). The agent must infer usage from the 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?
No annotations are provided, so the description carries full burden. It mentions retrieval but doesn't disclose behavioral traits like whether this is paginated (implied by 'page' parameter but not stated), rate limits, authentication requirements, or what format the returned list takes. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a straightforward retrieval operation and gets straight to the point without unnecessary elaboration.
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 retrieval tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the return value looks like (list format, fields included), doesn't mention pagination behavior despite having a page parameter, and provides no context about error conditions or limitations. The description leaves too many operational questions unanswered.
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 three parameters (category, page, sort) with descriptions, defaults, and enum values. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('取得する' - get/retrieve) and resource ('カテゴリーに含まれる記事一覧' - list of articles in a category). It's specific about what it retrieves, though it doesn't explicitly distinguish from similar sibling tools like 'get-user-notes' or 'search-notes' which might also retrieve articles.
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 many sibling tools that retrieve notes/articles (e.g., 'get-user-notes', 'search-notes', 'get-membership-notes'), there's no indication of when this category-specific retrieval is preferred over other filtering methods.
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 the action ('get comments') without any details on permissions, rate limits, pagination, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves in practice.
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 that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently conveys the core purpose, making it easy to parse quickly. There is no wasted verbiage or structural issues.
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 for effective tool use. It does not explain what the return value includes (e.g., comment structure, metadata) or any behavioral aspects like error handling. For a tool with one parameter but no structured output information, more context is needed to ensure the agent can invoke it correctly.
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 'noteId' clearly documented as '記事ID' (article ID). The description does not add any extra meaning beyond this, such as format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
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 'Get a list of comments on an article.' This specifies the verb ('get') and resource ('comments on an article'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'get-note' or 'post-comment,' which is why it scores a 4 instead of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a valid noteId, or compare it to related tools like 'get-note' (which might include comments) or 'post-comment' (for adding comments). Without any usage context, the agent must infer this 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('get hashtag details') without mentioning permissions, rate limits, error handling, or what 'details' entail (e.g., metadata, usage statistics). This leaves significant gaps for an agent to understand how the tool behaves beyond basic input-output.
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'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 complexity (a read operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'details' include in the return values, potential errors, or behavioral aspects like caching or permissions. This makes it inadequate for an agent to fully understand the tool's context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'tag' documented as 'ハッシュタグ名' (hashtag name). The description doesn't add any extra meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3 even without additional param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ハッシュタグの詳細を取得する' (Get hashtag details) clearly states the verb '取得する' (get) and resource 'ハッシュタグの詳細' (hashtag details), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-hashtags' or 'search-all', which might also involve hashtag-related operations, so it doesn't reach the highest 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. There are sibling tools such as 'list-hashtags' and 'search-all' that might overlap in functionality, but the description doesn't specify contexts, prerequisites, or exclusions for usage.
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 the action (get likes) but lacks behavioral details: it doesn't specify if this is a read-only operation, what the output format is (e.g., list of users, count), whether there are rate limits, authentication requirements, or pagination. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with one parameter) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list structure, error cases) or behavioral aspects like safety or constraints. For a tool with no structured data beyond the input schema, more context 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 'noteId' clearly documented as '記事ID' (article ID). The description adds no additional meaning beyond the schema, such as format examples (e.g., numeric vs. string ID) or context (e.g., where to find the ID). With high schema coverage, the baseline score of 3 is appropriate 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 '記事のスキ一覧を取得する' (Get a list of article likes) clearly states the verb (取得する/get) and resource (記事のスキ/likes of an article). It distinguishes from siblings like 'like-note' (adds likes) and 'unlike-note' (removes likes) by focusing on retrieval. However, it doesn't explicitly differentiate from other list tools like 'get-comments' or 'get-user-notes' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid noteId), exclusions, or comparisons to similar tools like 'get-note' (which might include likes) or 'get-user-notes' (which lists notes rather than likes). Usage is implied by the name but not explicitly stated.
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 retrieves a list but doesn't describe what 'notes' contain, whether the operation is safe/read-only, if authentication is needed, pagination behavior beyond parameters, or rate limits. This leaves significant gaps for a tool that likely interacts with user data.
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 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?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'notes' are, their format, or the return structure. Given the complexity of retrieving user data and multiple sibling tools for similar operations, more context is needed for proper 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%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying it retrieves notes for a membership. This 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 (取得する/get) and resource (メンバーシップの記事一覧/membership notes list). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'get-user-notes' or 'get-category-notes' which might retrieve similar note lists for different scopes.
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 sibling tools like 'get-user-notes' or 'get-category-notes' that might retrieve notes for different contexts, nor does it specify prerequisites or exclusions for usage.
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 it's a read operation ('取得する' - get), which implies safety, but doesn't cover aspects like authentication needs, rate limits, pagination, or what the return format looks like (since no output schema exists). This leaves significant gaps for a tool that likely returns user data.
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 the tool likely returns user membership data (a read operation with potential complexity), the description is incomplete. With no annotations and no output schema, it fails to explain return values, error conditions, or behavioral traits. For a tool in a context with many sibling tools, more guidance on output and usage would be beneficial.
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 information, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.
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 joined memberships) states a clear verb ('取得する' - get) and resource ('加入済みメンバーシップ一覧' - list of joined memberships), but it's vague about scope and doesn't differentiate from sibling tools like 'get-membership-plans' or 'get-test-membership-summaries'. 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 is provided on when to use this tool versus alternatives like 'get-membership-plans' (which might show available plans rather than joined ones) or 'get-test-membership-summaries' (which might be for testing). The description implies usage for retrieving joined memberships but offers no explicit when/when-not instructions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool retrieves a list including drafts, which implies read-only behavior, but doesn't disclose pagination behavior (implied by parameters but not stated), authentication requirements, rate limits, error conditions, or what the return format looks like. For a list retrieval tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple list retrieval tool. However, it could be slightly more structured by explicitly mentioning pagination or filtering capabilities.
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 moderate complexity (list retrieval with filtering/pagination), no annotations, and no output schema, the description is minimally adequate. It covers what's retrieved (user's articles including drafts) but lacks information about return format, error handling, authentication needs, or how it differs from sibling tools. The schema handles parameters well, but overall context is incomplete.
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 three parameters well-documented in the schema (page, perPage, status with enum values). The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '取得する' (get/retrieve) and resource '自分の記事一覧' (list of my articles), including the scope '下書きを含む' (including drafts). It distinguishes from general note retrieval tools like 'get-note' or 'get-user-notes' by specifying it's for the user's own articles. However, it doesn't explicitly differentiate from all sibling tools like 'get-membership-notes' or 'search-notes' beyond the 'my' aspect.
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 choose this over 'get-user-notes' (which might retrieve notes for any user), 'search-notes' (which might have different filtering capabilities), or 'get-membership-notes' (which might retrieve notes from membership contexts). The agent must infer usage from the name and description 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 it's a read operation ('get'), which implies non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes. 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 ('記事の詳細情報を取得する'), which translates to 'Get detailed information of an article.' It's front-loaded with the core action and resource, with no wasted 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 tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'detailed information' entails, potential return values, or behavioral traits like safety or performance. For a read operation, more context is needed to guide the agent effectively, making it inadequate overall.
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 noteId clearly documented as '記事ID（例: n4f0c7b884789）'. The description doesn't add any extra meaning about parameters beyond what the schema provides, such as format constraints or examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 purpose: 'get detailed information of an article.' It specifies the verb (取得/get) and resource (記事/article), making it understandable. However, it doesn't explicitly differentiate from sibling tools like get-user-notes or get-my-notes, which might also retrieve notes but in different contexts, so it doesn't reach the highest 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 needing a specific note ID, or compare it to similar tools like get-user-notes or search-notes, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('get search history') without any details on permissions, rate limits, data format, or other behavioral traits. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Japanese ('検索履歴を取得する') that directly states the tool's purpose without any 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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'search history' entails (e.g., user-specific, system-wide, time range), the return format, or any prerequisites. For a tool with no structured data to rely on, this leaves critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 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 meets the baseline of 4 for this case, as it doesn't introduce confusion about 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 '検索履歴を取得する' (Get search history) clearly states the verb ('取得する' - get) and resource ('検索履歴' - search history), which meets the basic requirement for purpose. However, it doesn't distinguish this tool from any sibling tools that might also retrieve search-related data, and the title is null, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given sibling tools like 'search-all', 'search-notes', 'search-users', and 'search-magazines', there's no indication of how this tool differs or when it's preferred, leaving the agent to guess based on the 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. While '取得する' (get/retrieve) implies a read operation, the description doesn't mention authentication requirements, rate limits, pagination behavior (despite a 'page' parameter), what format the statistics are returned in, or whether this is a real-time or cached view. For a statistics retrieval tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that gets straight to the point. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a straightforward data retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistics retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'PV統計情報' (PV statistics) actually contains, the format of the response, whether it's aggregated or detailed data, or any behavioral aspects like authentication or rate limiting. The high schema coverage helps with parameters, but the overall context for using this tool is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself (filter with enum values, page number, sort with enum values). The description doesn't add any parameter-specific information beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate - 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 verb ('取得する' - get/retrieve) and resource ('ダッシュボードのPV統計情報' - dashboard PV statistics), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'get-user-notes' or 'get-search-history', but the resource specificity is clear enough to differentiate it from most other tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-user-notes', 'get-magazine', 'get-search-history', and various analytics tools, there's no indication of when dashboard PV statistics are appropriate versus other data retrieval tools. No exclusions or prerequisites 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While '取得する' (get) implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what constitutes '詳細情報' (detailed information). The description doesn't mention whether this is a public API or requires specific permissions, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place in conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a user retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what '詳細情報' (detailed information) includes, what format the response takes, or any error scenarios. Given the complexity of user data and the lack of structured output documentation, the description should provide more context about the returned data structure.
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 'username' parameter fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ユーザーの詳細情報を取得する' (Get user details) clearly states the verb ('取得する' - get) and resource ('ユーザーの詳細情報' - user details). It's specific about retrieving detailed information rather than just basic data. However, it doesn't differentiate from potential sibling tools like 'search-users' or 'get-user-notes', which would require explicit comparison.
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 sibling tools like 'search-users' and 'get-user-notes' available, there's no indication whether this tool retrieves a single user by exact username while 'search-users' might handle partial matches or multiple users. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' a list, implying a read operation, but doesn't disclose behavioral traits like pagination behavior (hinted by the 'page' parameter), rate limits, authentication needs, error conditions, or what constitutes 'articles' in this context. The description is minimal and leaves critical behavioral aspects unspecified.
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 that directly states the purpose. It's appropriately sized for a simple retrieval tool, with no wasted words. However, it could be slightly more structured by front-loading key details like scope or limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks context on what 'articles' are, how results are returned (e.g., list format, pagination details), error handling, or authentication requirements. For a tool with siblings like 'get-my-notes', more differentiation would help. The description is minimal and leaves gaps for the 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?
Schema description coverage is 100%, with both parameters ('username', 'page') fully described in the schema. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain format of 'username', what 'page' controls, or default behavior). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 user's articles) clearly states the verb ('取得する' - get) and resource ('ユーザーの記事一覧' - user's article list). It distinguishes from siblings like 'get-note' (single note) and 'search-notes' (search across notes), but doesn't explicitly differentiate from 'get-my-notes' (which likely gets the current user's notes). The purpose is specific but could be more precise about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-my-notes' (for current user), 'search-notes' (for broader searches), or 'get-note' (for a single note). There's no mention of prerequisites, context, or exclusions. Usage is implied by the name and description 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 the full burden of behavioral disclosure. It states the tool opens an editing page, implying a UI interaction or navigation, but doesn't clarify if this is a read-only preview, requires authentication, modifies data, or has side effects. For a tool with potential mutation implications, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese ('記事の編集ページを開く') that directly states the tool's function. It is front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence contributes to understanding the 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 lack of annotations and output schema, the description is incomplete for a tool that likely involves UI navigation or editing. It doesn't explain what 'opening' entails (e.g., redirect, new window, API response), potential errors, or behavioral outcomes. For a tool with one parameter but unclear behavior, 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?
The input schema has 100% description coverage, with 'noteId' clearly documented as a string with an example. The description doesn't add any parameter details beyond the schema, such as format constraints or usage context. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 (open) and target (note editing page) in Japanese, making the purpose understandable. It specifies opening an editor rather than just viewing or creating, which distinguishes it from siblings like 'get-note' or 'post-draft-note'. However, it doesn't explicitly differentiate from similar tools like 'add-magazine-note' in terms of scope 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing note ID), exclusions (e.g., not for creating new notes), or compare to siblings like 'get-note' for viewing or 'post-draft-note' for creating. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '投稿する' (post) implies a write/mutation operation, but the description doesn't mention authentication requirements, rate limits, error conditions, or what happens after posting (e.g., does it return the created comment?). This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese phrase that directly states the tool's function without any wasted words. It's appropriately concise and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what errors might occur, authentication requirements, or how it differs from related tools. The agent would need to guess about important behavioral aspects.
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 both parameters clearly documented in the schema (noteId and text). The description doesn't add any additional parameter semantics beyond what's in the schema, which is acceptable given the high schema coverage. The baseline of 3 is appropriate 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 (投稿する/post) and target resource (記事/note), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-comments' or 'like-note' which are related to comments but serve different functions.
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 several sibling tools related to notes and comments (e.g., 'get-comments', 'like-note', 'post-draft-note'), but the description doesn't specify when this tool is appropriate or what prerequisites might be needed.
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 full burden. It mentions Markdown-to-HTML conversion but lacks critical behavioral details: whether this is a write operation (implied by 'post'), authentication requirements, rate limits, error conditions, or what happens on success/failure. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys core functionality. No wasted words, though it could be more front-loaded with key behavioral details. The Japanese text is clear and direct.
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?
Incomplete for a mutation tool with no annotations and no output schema. The description lacks essential context: authentication needs, what 'posting' entails (publishing live?), error handling, return values, and how it differs from sibling tools. For a 4-parameter write operation, this 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting, though the description could have explained parameter interactions (e.g., 'id' for updates vs. new posts).
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 ('投稿する' - post/publish) and resource ('下書き状態の記事' - draft article), specifying it converts Markdown to HTML. It doesn't explicitly differentiate from siblings like 'add-magazine-note' or 'post-comment', but the focus on draft articles provides some implicit 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?
No explicit guidance on when to use this tool versus alternatives. The description mentions converting Markdown to HTML, but doesn't specify prerequisites (e.g., authentication), when to use 'id' parameter for updates, or how it differs from similar tools like 'add-magazine-note' or 'post-comment'.
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 what the tool searches for, without mentioning how results are returned, pagination behavior, rate limits, authentication requirements, or any side effects. For a search tool with 5 parameters and no output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese phrase that efficiently communicates the core functionality. Every word earns its place, and there's no wasted verbiage. The structure is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what the search returns, how results are structured, or any behavioral characteristics. For a search tool that likely returns complex results across multiple entity types, more context about the output format and behavior would be necessary for 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?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions the search targets (user, hashtag, note) which aligns with the 'context' parameter, but this is redundant with the schema. Baseline 3 is appropriate 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 tool's purpose as 'note全体検索' (note-wide search) and specifies the search targets: users, hashtags, and notes. It uses a specific verb ('検索' - search) and identifies the resource scope. However, it doesn't explicitly distinguish this from sibling tools like 'search-notes' or 'search-users', which appear to be more targeted searches.
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 multiple sibling search tools (search-notes, search-users, search-magazines), there's no indication of when this comprehensive search is preferred over the more specific ones. No prerequisites, exclusions, or comparative context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action (delete a like) but doesn't disclose behavioral traits such as permissions required, whether the operation is idempotent, error conditions (e.g., if the note doesn't exist or isn't liked), or what happens on success (e.g., no return value or confirmation). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. It's 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 complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral aspects like error handling, return values, or side effects. While the purpose is clear, the tool's full context isn't adequately covered for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter semantics beyond what the input schema provides. The schema has 100% description coverage with 'noteId' clearly documented as '記事ID' (note ID). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 '記事のスキを削除する' (Delete a note's like) clearly states the action (delete) and resource (note's like). It distinguishes from siblings like 'like-note' (which adds likes) and 'get-likes' (which retrieves likes). However, it doesn't specify the exact resource type (e.g., 'unlike' vs 'remove like'), 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 prerequisites (e.g., a note must exist and be liked first), exclusions, or comparisons to sibling tools like 'like-note' or 'get-likes'. The agent must infer usage from the purpose 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. It mentions 'ダミーデータ' (dummy data), indicating this returns mock data, which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., format, pagination). For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese: 'テスト用：メンバーシップの記事一覧をダミーデータで取得する'. It's front-loaded with the testing purpose and clearly states the action and resource. There's no wasted text, though it could be slightly more structured for clarity.
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 tool with 3 parameters (one required), the description is incomplete. It covers the testing purpose and dummy data aspect but lacks details on behavior, output format, and usage distinctions from siblings like 'get-membership-notes'. For a tool in this 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 all parameters documented in the schema (membershipKey, page, perPage). The description doesn't add any parameter-specific semantics beyond what the schema provides, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate 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 purpose: 'テスト用：メンバーシップの記事一覧をダミーデータで取得する' (Test: Get a list of membership articles with dummy data). It specifies the verb '取得する' (get), resource 'メンバーシップの記事一覧' (membership article list), and scope 'テスト用' (for testing) with dummy data. However, it doesn't explicitly differentiate from sibling tools like 'get-membership-notes', which appears to be a non-test version, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'テスト用' (for testing), suggesting this tool should be used for testing purposes rather than production. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'get-membership-notes' or other note-related tools, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action ('取得する' - get) without describing what '一覧' (list) entails - whether it returns all contests, is paginated, requires authentication, has rate limits, or what format the data comes in. For a read operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what data is returned, in what format, whether authentication is required, or any behavioral characteristics. While the tool is simple (0 parameters), the description should provide more context about the operation's behavior and results.
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 with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the schema already indicates.
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 contest list) clearly states the verb ('取得する' - get) and resource ('コンテスト一覧' - contest list). It distinguishes from siblings like 'list-categories' or 'list-hashtags' by specifying contests, but doesn't explicitly differentiate from other list operations beyond naming the resource.
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. There's no mention of prerequisites, timing, or comparison with other tools like 'search-all' or 'search-notes' that might also retrieve contest-related data. The description only states what it does, not when to use it.
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 basic operation. It doesn't disclose behavioral traits like whether this is a read-only operation (implied but not explicit), pagination, rate limits, authentication requirements, or what format the list returns. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that presumably returns a list. It doesn't explain what the list contains (e.g., hashtag names, IDs, counts), format, or any constraints. For a retrieval tool in this context, more information about the return value would be helpful.
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 with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ハッシュタグ一覧を取得する' clearly states the action (取得する - get/retrieve) and resource (ハッシュタグ一覧 - list of hashtags), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-hashtag' (singular vs. list), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get-hashtag' (for single hashtag) or 'search-all' (which might include hashtags). The description only states what it does, not when it's 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a read operation ('取得する') but doesn't mention authentication requirements, rate limits, pagination, error conditions, or what format the membership plan data returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the 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?
For a zero-parameter read operation with no output schema, the description provides the basic purpose but lacks important context. Without annotations covering authentication, rate limits, or return format, and with no output schema to document the response structure, the description should do more to compensate for these gaps in 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't add parameter information beyond what's already covered, maintaining a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得する' - get/retrieve) and resource ('自分のメンバーシッププラン一覧' - my membership plan list), making the purpose understandable. It doesn't explicitly differentiate from siblings like 'get-membership-notes' or 'get-membership-summaries', but the resource specificity provides some 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?
No guidance is provided on when to use this tool versus alternatives like 'get-membership-notes' or 'get-membership-summaries'. The description only states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '取得する' implies a read operation, it doesn't specify whether this requires authentication, returns paginated results, has rate limits, or provides error handling. The description lacks critical behavioral context for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple list operation and front-loads the 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?
For a simple list tool with no parameters and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more behavioral context about what the list contains, format, or usage constraints. The description meets basic requirements but leaves gaps in completeness.
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 with 100% schema description coverage. The description doesn't need to explain parameters, and it correctly doesn't mention any. Since there are no parameters to document, this meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'カテゴリー一覧を取得する' clearly states the action (取得する - get/retrieve) and resource (カテゴリー一覧 - category list). It distinguishes from siblings like 'list-contests' or 'list-hashtags' by specifying categories. However, it doesn't explicitly differentiate from similar list operations beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for usage, or comparison with sibling tools like 'get-category-notes' or 'search-all' that might retrieve category-related information differently.
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 discloses that the tool returns dummy data, which is a key behavioral trait not inferable from the schema. However, it doesn't mention other aspects like rate limits, authentication needs, or response format. The description adds some value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that front-loads the key information (testing purpose and resource). Every word earns its place, with no wasted text, 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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and testing context but doesn't cover behavioral details like response format or error handling. For a read-only tool with dummy data, more context on output expectations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters. A baseline of 4 is appropriate as it doesn't need to compensate for any gaps.
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: 'テスト用：加入済みメンバーシップ一覧をダミーデータで取得する' (Test: Get a list of subscribed memberships with dummy data). It specifies the verb ('取得する' - get) and resource ('加入済みメンバーシップ一覧' - list of subscribed memberships), and distinguishes it from siblings like 'get-membership-summaries' by indicating it's for testing with dummy data. However, it doesn't explicitly differentiate from 'get-test-membership-notes' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it's for testing purposes ('テスト用'), which implies it should be used in test scenarios rather than production. It doesn't explicitly state when not to use it or name alternatives, but the testing context is sufficient guidance. No misleading information is present.
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:

[![note-com-mcp MCP server](https://glama.ai/mcp/servers/shimayuz/note-com-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shimayuz/note-com-mcp)

Score Badge

Copy to your README.md:

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

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