Qiita API MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources (items, comments, tags, users) and actions (create, get, update, delete, follow/unfollow, stock/unstock). No ambiguity exists—for example, get_item retrieves a single article while get_items lists multiple, and follow_user/unfollow_user are complementary opposites.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case (e.g., create_item, get_user, update_comment). The naming is highly predictable, with verbs like get, create, update, delete, follow, unfollow, stock, unstock, and is applied uniformly across resources.
Tool Count3/5
With 30 tools, the count is borderline high for a typical MCP server, though it covers a comprehensive social blogging platform (Qiita). While each tool serves a purpose, the number might feel heavy compared to simpler APIs, but it's justified by the domain's complexity.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for all core resources (items, comments, tags, users), including follow/unfollow and stock/unstock operations. There are no obvious gaps—every major action an agent would need for interacting with Qiita's API is available.
Average 2.9/5 across 30 of 30 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 but provides minimal information. It states the tool retrieves items but doesn't mention authentication requirements, rate limits, pagination behavior beyond what's in the schema, error conditions, or what format the returned items will have. For a retrieval tool with zero annotation coverage, this leaves significant behavioral unknowns.
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 sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. While it may be too brief for complete understanding, it's structurally efficient with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (retrieving items with filtering/pagination), lack of annotations, no output schema, and multiple similar sibling tools, the description is inadequate. It doesn't explain what 'items' are, how they differ from other content types, what fields are returned, or when to choose this over other retrieval tools. The description leaves too many contextual 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?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for page, perPage, and query parameters. The baseline score of 3 is appropriate since the schema fully documents all parameters, though the description could have added context about how query filtering works or what 'items' specifically means.
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 list of articles) states the basic action but is vague about scope and differentiation. It doesn't specify what type of items are retrieved (articles vs other content) or how it differs from similar sibling tools like get_item, get_tag_items, or get_user_items. The purpose is stated but lacks specificity needed for clear tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve items (get_item, get_tag_items, get_user_items, get_user_stocks), there's no indication whether this retrieves all items, recently published items, or items matching specific criteria. The agent must guess based on tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions getting a list of articles but doesn't describe the return format, pagination behavior, error handling, or any rate limits. This is a significant gap for a tool with no 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 sentence in Japanese that directly states the tool's purpose. It's front-loaded with no wasted words, 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 the complexity (a read operation with pagination), no annotations, and no output schema, the description is incomplete. It doesn't explain what the returned list contains, how results are formatted, or any behavioral traits, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'tagId', 'page', and 'perPage'. The description doesn't add any meaning beyond this, such as explaining what a 'tagId' represents or how pagination works. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '指定されたタグの記事一覧を取得します' (Get a list of articles for a specified tag), which clearly indicates the verb (get) and resource (articles for a tag). However, it doesn't distinguish this from sibling tools like 'get_items' (which likely gets all items) or 'get_user_items' (which gets items by user), leaving the purpose somewhat vague in 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 sibling tools like 'get_items' or 'get_user_items', nor does it specify prerequisites or exclusions, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('stocks') but doesn't clarify what 'stocking' entails (e.g., saving, bookmarking, or adding to a list), whether it's idempotent, requires authentication, or has side effects. This leaves critical behavioral traits unspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 tool's action. It's front-loaded with the core purpose, though it could be slightly more informative without sacrificing brevity, earning a high score for 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 is a mutation (implied by 'stocks') with no annotations and no output schema, the description is incomplete. It lacks details on behavior, return values, error conditions, or how it fits with siblings like 'unstock_item', making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'itemId' clearly documented as '記事ID' (article ID). The description doesn't add any meaning beyond this, such as format examples or sourcing details, but the schema provides adequate information, meeting the baseline for high 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 '指定された記事をストックします' (Stocks the specified article) provides a basic verb+resource combination, stating the action (stock) and target (article). However, it doesn't differentiate from sibling tools like 'unstock_item' or explain what 'stocking' means in this context beyond the literal translation, making it somewhat vague.
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. It doesn't mention prerequisites (e.g., authentication), when not to use it (e.g., if already stocked), or refer to related tools like 'unstock_item' or 'is_item_stocked' for checking status, leaving the agent without context for decision-making.
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 states it 'retrieves' information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function. It's front-loaded with the core purpose and has no wasted words, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'detailed information' includes, how errors are handled, or any behavioral traits. For a retrieval tool in a context with many siblings, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'commentId' documented as 'comment ID' in the schema. The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose as 'retrieves detailed information of a specified comment' which is clear but generic. It uses a specific verb ('retrieves') and resource ('comment'), but doesn't distinguish it from sibling tools like 'get_item_comments' or 'update_comment' that also involve comments. The purpose is understandable but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_item_comments' (for multiple comments) and 'update_comment' (for modifying), there's no indication of context, prerequisites, or exclusions. This leaves the agent to infer usage from 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 full burden. It states it 'retrieves' information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the itemId is invalid. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. It's appropriately sized and front-loaded with no 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 the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but incomplete. It doesn't cover what 'detailed information' includes, authentication needs, or error handling. For a read operation in a context with many sibling tools, more context would help the agent use 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 itemId documented as '記事ID' (article ID). The description adds no additional meaning beyond this, as it doesn't explain format, constraints, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate or add value.
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 '指定された記事の詳細情報を取得します' (Retrieves detailed information of the specified article) clearly states the action (retrieves) and resource (article details), but it's vague about what 'detailed information' includes. It distinguishes from siblings like get_items (plural) and get_item_comments, but doesn't specify how it differs from other get_* tools that might also retrieve article-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), when not to use it, or compare it to siblings like get_items (for listing) or get_item_comments (for comments only). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states it 'gets a tag list', without mentioning pagination behavior (implied by parameters), rate limits, authentication needs, or what the return format looks like (e.g., list of tag objects). For a read operation with no 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 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. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 3 parameters, the description is incomplete. It doesn't explain what the tool returns (tag objects with what fields?), how pagination works, or any error conditions. For a list operation with pagination parameters, more context about the return structure and behavior would be needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'page', 'perPage', and 'sort' parameters including defaults and constraints. The description adds no additional parameter semantics beyond what's in the schema. 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 'タグ一覧を取得します' (Get tag list) clearly states the verb ('取得します' - get) and resource ('タグ一覧' - tag list), providing a basic purpose. However, it doesn't distinguish this from sibling tools like 'get_tag' (singular) or 'get_tag_items', leaving ambiguity about scope. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_tags' (list) over 'get_tag' (singular) or 'get_tag_items', nor does it specify any prerequisites or context for usage. There's no explicit or implied usage guidance beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('get user list') without revealing any behavioral traits: it doesn't mention pagination behavior (implied by parameters but not described), authentication requirements, rate limits, what data is returned, or whether this is a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately. Every word earns its place without being overly terse or verbose.
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 the description provides minimal context, this is incomplete for effective use. The description doesn't explain what kind of user data is returned, how results are structured, or any behavioral constraints. For a paginated list tool in a system with multiple user-related tools, more context about scope and output would be needed for the agent to use 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?
Schema description coverage is 100%, with both parameters (page, perPage) fully documented in the schema with descriptions, types, defaults, and ranges. The description adds no parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ユーザー一覧を取得します' (Get user list) clearly states the verb ('取得します' - get/retrieve) and resource ('ユーザー一覧' - user list), providing a basic purpose. However, it doesn't distinguish this from sibling tools like get_user (singular) or get_authenticated_user, making it vague about scope differentiation. The purpose is understandable but lacks specificity about what kind of user list this returns.
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 get_user (for a specific user), get_authenticated_user (for the current user), and get_user_followers/followees (for relationship data), there's no indication of when this paginated list tool is appropriate versus those more targeted tools. No usage context, exclusions, or alternatives 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 creates a comment, implying a write operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, side effects (e.g., notifications), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing to understanding the action and target.
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 is a mutation (creates a comment) with no annotations, no output schema, and 100% schema coverage, the description is incomplete. It lacks details on authentication, response format, error handling, or interaction with siblings (e.g., 'get_item_comments'). For a write operation, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('itemId', 'body') fully documented in the schema. The description adds no additional meaning beyond the schema, such as format details for 'itemId' or examples for 'body'. Baseline is 3 since the schema does the heavy lifting, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('作成します' - creates) and target resource ('コメント' - comment) with context ('指定された記事に' - on the specified article). It distinguishes from siblings like 'update_comment' or 'delete_comment' by specifying creation, but doesn't explicitly differentiate from other creation tools like 'create_item' 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or compare with related tools like 'update_comment' for editing or 'get_item_comments' for reading. The description only states what it does, not when to invoke 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?
No annotations are provided, so the description carries full burden. It states 'creates' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether creation is idempotent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized 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 (create operation) with no annotations and no output schema, the description is incomplete. It doesn't address what happens after creation (e.g., returns the created item ID), error conditions, authentication requirements, or side effects like the tweet parameter's Twitter posting. The agent lacks crucial context for proper tool invocation.
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 fully documented in the schema. The description adds no additional meaning about parameters beyond implying article creation. It doesn't explain parameter relationships, constraints, or usage examples. With high schema coverage, baseline 3 is appropriate when description doesn't enhance parameter understanding.
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 '新しい記事を作成します' (creates a new article) clearly states the verb (create) and resource (article). It distinguishes from siblings like update_item, delete_item, and get_item by specifying creation rather than modification, retrieval, or deletion. However, it doesn't explicitly differentiate from create_comment, which creates a different 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. There's no mention of prerequisites (e.g., authentication), when not to use it, or explicit alternatives like update_item for modifying existing articles. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('delete') without details on side effects (e.g., if it's destructive, requires confirmation, affects related data), error handling, or response format. For a mutation 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, clear sentence in Japanese that directly states the tool's action without unnecessary words. It's front-loaded and efficiently conveys the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations and no output schema, the description is incomplete. It lacks critical context such as behavioral traits (e.g., permanence, permissions), error cases, or what happens post-deletion, which is essential 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add parameter semantics beyond the input schema, which has 100% coverage and clearly documents the single required 'commentId' parameter. With only one parameter fully described in the schema, the baseline is high even without extra details 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 action ('削除します' - delete) and target ('コメント' - comment), which clarifies the tool's basic purpose. However, it doesn't differentiate from sibling tools like 'delete_item' or specify what type of comment system this is (e.g., blog, forum, document). The purpose is clear but lacks specificity about 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 like 'update_comment' or prerequisites such as authentication. It doesn't mention if deletion is permanent, reversible, or requires specific permissions, leaving the agent with no usage context beyond the basic action.
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 '削除します' clearly indicates a destructive operation, it doesn't specify whether deletion is permanent/reversible, what permissions are required, whether it cascades to related data (comments/stocks), or what confirmation/response to expect. For a destructive 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 function without any unnecessary words. It's perfectly front-loaded with the core action and resource, making it immediately comprehensible.
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 destructive operation tool with no annotations and no output schema, the description is insufficient. It doesn't address critical context like authentication requirements, error conditions, what happens to associated data (comments/stocks), or what the tool returns upon success/failure. Given the complexity and risk of deletion operations, more completeness 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 description doesn't add any parameter information beyond what's already in the schema (100% coverage). The schema fully documents the single required 'itemId' parameter with its Japanese description '記事ID' (article ID). The description's mention of '指定された記事' (specified article) aligns with but doesn't expand upon the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('削除します' - deletes) and the resource ('指定された記事' - specified article), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'delete_comment' or 'unstock_item', but the resource type (article vs comment/stock) provides 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?
The description provides no guidance on when to use this tool versus alternatives like 'update_item' for modification or 'get_item' for viewing. There's no mention of prerequisites (authentication needs), consequences, or appropriate contexts for deletion versus other operations on articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (follow a tag) but doesn't describe what 'follow' entails (e.g., notifications, updates), whether it requires authentication, if it's idempotent, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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 ('指定されたタグをフォローします'), which directly states the action without waste. It's appropriately sized and front-loaded, with every word contributing to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations, 1 parameter, no output schema), the description is incomplete. It lacks details on behavior, authentication needs, return values, or error handling. For a follow action, more context (e.g., what 'follow' means, idempotency) would help the agent use 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?
Schema description coverage is 100%, with the single parameter 'tagId' documented in the schema as 'タグID' (tag ID). The description doesn't add any meaning beyond this (e.g., format, source, or examples). Baseline is 3 since the schema does the heavy lifting, but no extra value is provided.
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 '指定されたタグをフォローします' (Follows the specified tag) clearly states the verb (follow) and resource (tag), making the purpose understandable. It distinguishes from siblings like follow_user (follows users) and unfollow_tag (unfollows tags), though it doesn't explicitly mention this differentiation. The purpose is specific but lacks explicit sibling 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. It doesn't mention prerequisites (e.g., authentication), when not to use it (e.g., if already following), or alternatives like is_tag_followed to check status first. Usage is implied by the action but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't mention authentication requirements, rate limits, whether following is reciprocal, what happens if the user doesn't exist, or what the response looks like. For a mutation 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 sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with one parameter.
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 inadequate. It doesn't explain what happens after following (e.g., success/failure response, error conditions), doesn't mention authentication requirements, and provides no context about the social following system's rules or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'userId' clearly documented in the schema. The description doesn't add any meaningful parameter information beyond what's already in the structured schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('follow') and target ('specified user'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'unfollow_user' or explain how it differs from 'is_user_followed', missing full 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 like 'unfollow_user', 'is_user_followed', or 'get_user_followees/followers'. There's no mention of prerequisites, constraints, or appropriate contexts for following a user.
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 such as whether this is a read-only operation (implied but not explicit), potential rate limits, authentication requirements, pagination behavior, or error conditions for invalid item IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without any fluff or redundant information. 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 for a tool that likely returns a list of comments. It doesn't explain what the return value includes (e.g., comment text, authors, timestamps) or handle edge cases, leaving significant gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the schema provides (100% coverage with 'itemId' clearly documented as '記事ID'). Since the schema fully describes the single parameter, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('取得します' - retrieve/get) and resource ('指定された記事のコメント一覧' - comments of a specified article), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_comment' (singular) or 'get_items' (articles vs comments), 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 on when to use this tool versus alternatives. For example, it doesn't mention whether to use 'get_comment' for a single comment or this tool for all comments of an article, nor does it specify prerequisites like needing the article ID from 'get_item' first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it retrieves a list, implying a read operation, but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what happens with invalid item IDs. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Japanese that directly states the tool's purpose. It's front-loaded with the core functionality and has no unnecessary words or fluff. Every part of the sentence contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, user details included), error conditions, or pagination details. For a tool with 3 parameters and no structured output information, the description should provide more context 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%, so the schema fully documents all parameters (itemId, page, perPage). The description doesn't add any meaning beyond what the schema provides—it mentions '指定された記事' (specified article) which corresponds to itemId but doesn't explain parameter interactions or usage. 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 verb ('取得します' - get/retrieve) and resource ('指定された記事をストックしたユーザー一覧' - list of users who stocked the specified article). It distinguishes from siblings like 'get_item' (gets article details) or 'get_user_stocks' (gets articles stocked by a user). However, it doesn't explicitly contrast with 'is_item_stocked' (checks if article is stocked), which would make it 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?
No guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_item_stockers' versus 'get_user_stocks' (which gets articles stocked by a user) or 'is_item_stocked' (which checks if an article is stocked). 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 mentions retrieving details but doesn't specify what '詳細情報' (detailed information) includes, whether authentication is required, error conditions, or response format. This leaves significant gaps for a tool that presumably fetches 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 without unnecessary words. It's appropriately sized and front-loaded with 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 no annotations and no output schema, the description is insufficient. It doesn't explain what '詳細情報' includes (e.g., tag name, description, usage count), potential errors (e.g., invalid tagId), or authentication needs. For a data retrieval tool, this leaves too much undefined.
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 'tagId' clearly documented as 'タグID' (tag ID). The description doesn't add any parameter details beyond what the schema provides, but since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('タグの詳細情報' - detailed tag information), making the purpose understandable. However, it doesn't differentiate this from sibling tools like 'get_tags' (plural) or 'get_tag_items', leaving room for ambiguity about when to use each.
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_tags' (which likely lists multiple tags) or 'get_tag_items' (which might retrieve items associated with a tag). The description only states what the tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does (retrieves user details) without mentioning whether it's a read-only operation, what permissions are required, how errors are handled, or the format of the returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 user retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what '詳細情報' (detailed information) includes, how the data is structured, or potential error conditions. This leaves the agent with insufficient context to understand the tool's full behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'userId' documented in the schema as 'ユーザーID'. The description doesn't add any meaning beyond this, such as explaining what constitutes a valid user ID or where to find it. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定されたユーザーの詳細情報を取得します' (Retrieves detailed information for a specified user). It uses a specific verb (取得/retrieve) and resource (ユーザーの詳細情報/user details). However, it doesn't explicitly differentiate from sibling tools like 'get_authenticated_user' or 'get_users', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_user' over 'get_authenticated_user' (for current user) or 'get_users' (for multiple users), nor does it specify prerequisites or exclusions. This leaves the agent without context for 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. It states the tool retrieves a list but doesn't mention pagination behavior (implied by parameters), rate limits, authentication needs, or what happens with invalid inputs. For a read operation 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 sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding what the tool does.
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 pagination), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return format, or pagination details, which are critical for an agent to use the tool effectively. The high schema coverage helps but doesn't compensate for missing context on outputs and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 100%, with clear documentation for userId, page, and perPage parameters. The description doesn't explain how these parameters interact (e.g., pagination for large follow lists) or provide additional context, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定されたユーザーのフォロー一覧を取得します' (Get the follow list of the specified user). It uses a specific verb ('取得します' - get/retrieve) and resource ('フォロー一覧' - follow list), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_user_followers' (which gets followers rather than followees), 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 sibling tools like 'get_user_followers' (for followers) or 'get_user' (for user details), nor does it specify prerequisites or contexts. The agent must infer usage from the tool 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 full burden for behavioral disclosure. It mentions retrieval but doesn't describe what format the articles are returned in, whether authentication is required, if there are rate limits, or how pagination works beyond the parameter descriptions. For a tool with 3 parameters and no annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a straightforward retrieval tool and gets straight to the point with no 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 inadequate. It doesn't explain what 'articles' means in this context, what fields are returned, whether authentication is needed, or how to interpret paginated results. The agent would need to guess about important behavioral aspects of 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?
The schema has 100% description coverage with clear parameter documentation in Japanese. The description doesn't add any additional semantic context about the parameters beyond what's already in the schema. With complete 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 clearly states the action ('取得します' - retrieves) and resource ('指定されたユーザーの記事一覧' - specified user's article list), making the purpose immediately understandable. It distinguishes from general 'get_items' by specifying user-scoped retrieval, though it doesn't explicitly differentiate from 'get_user_stocks' which retrieves different content.
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_items' (general items) or 'get_user_stocks' (user's stocked items). The description only states what it does, not when it's appropriate or what distinguishes it from sibling tools in the same domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While '取得します' (get/retrieve) implies a read-only operation, the description doesn't specify authentication requirements, rate limits, pagination behavior (beyond what's in the schema), error conditions, or what format the stock list returns. For a tool with 3 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'stocks' represent in this context (e.g., saved items, bookmarks, investments), how results are structured, or any behavioral aspects like error handling. For a data retrieval tool in a system with many related tools, 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%, so the schema already fully documents all three parameters (userId, page, perPage) with their types, descriptions, defaults, and constraints. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('指定されたユーザーのストック一覧' - specified user's stock list), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'get_item_stockers' or 'is_item_stocked', which also deal with stock-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for use, or comparison to sibling tools like 'get_user_items' or 'get_item_stockers' that might retrieve related data. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks stock status but doesn't reveal if it requires authentication, has rate limits, returns errors for invalid items, or provides any metadata beyond a boolean. For a read operation with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence contributes 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a boolean, error details, or stock metadata), authentication requirements, or error handling. For a tool in a context with many sibling operations, more context is needed to use it effectively alongside alternatives.
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 ('記事ID' - article ID), so the schema fully documents the parameter. The description adds no additional semantic context beyond implying 'itemId' refers to an article. 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 clearly states the tool's purpose: '指定された記事がストックされているかどうかを確認します' (Check if the specified article is stocked). It uses a specific verb ('確認します' - check/verify) and resource ('記事' - article), making the function unambiguous. However, it doesn't explicitly distinguish itself from sibling tools like 'get_user_stocks' or 'get_item_stockers', which might provide related stock information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication), compare with sibling tools (e.g., 'get_user_stocks' for listing stocked items or 'get_item_stockers' for seeing who stocked an item), or specify scenarios where this boolean check is preferred over other stock-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks follow status but doesn't reveal whether it requires authentication, returns a boolean or detailed response, has rate limits, or handles errors. For a query tool with zero 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 sentence in Japanese that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. 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 query tool. It doesn't explain what the return value will be (e.g., boolean, object with status), error conditions, or authentication requirements. While the purpose is clear, the missing behavioral and output details hinder full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'tagId' documented as 'タグID' (tag ID). The description adds no additional meaning beyond this, such as format examples or source of the tag ID. With high schema coverage, the baseline is 3, as the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定されたタグをフォローしているかどうかを確認します' (Check whether the specified tag is being followed). It uses a specific verb ('確認します' - check/verify) and resource ('タグ' - tag), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'follow_tag' or 'unfollow_tag', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare it to similar tools like 'is_user_followed', or specify scenarios where this check is needed (e.g., before following/unfollowing). Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('unfollow') but doesn't clarify whether this is a destructive operation, requires authentication, has side effects (e.g., notifications), or what happens on success/failure. This leaves critical behavioral traits unspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly conveys the core action without unnecessary words. It's front-loaded with the key information, making it highly concise and well-structured for quick comprehension.
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 the outcome (e.g., what 'unfollowed' means, return values, or error conditions), leaving gaps in understanding the tool's full behavior and integration 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?
The schema description coverage is 100%, with the single parameter 'tagId' clearly documented in the schema. The description doesn't add any semantic details beyond what the schema provides (e.g., format examples or sourcing guidance), so it meets the baseline for high schema coverage without extra value.
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 ('unfollow') and the resource ('tag'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'unfollow_user' beyond the resource type, nor does it specify what 'unfollowing' entails in this context (e.g., removing from a personal list vs. public subscription).
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 'unfollow_user' or 'is_tag_followed'. It lacks context such as prerequisites (e.g., must be following the tag first) or typical scenarios for unfollowing tags, leaving the agent to infer usage from 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. It states the action ('unfollows') but does not cover critical aspects such as permissions required, whether the operation is idempotent, error conditions (e.g., if the user is not followed), or side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for a simple tool, making it easy to parse and understand 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 for a mutation tool. It does not explain what happens upon success (e.g., confirmation message, state change) or failure, nor does it address behavioral traits like idempotency or error handling. For a tool that modifies user relationships, this leaves too much unspecified.
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 'userId' clearly documented as 'ユーザーID' (user ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the documentation adequately.
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 ('unfollow') and target resource ('user') in Japanese, translating to 'Unfollows the specified user.' This is specific and unambiguous about what the tool does. However, it does not explicitly differentiate from sibling tools like 'unfollow_tag' or 'is_user_followed,' which slightly limits its clarity in 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 does not mention prerequisites (e.g., the user must be currently followed), exclusions, or related tools like 'follow_user' or 'is_user_followed.' Without such context, an agent might misuse it or overlook necessary checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('unstock') but doesn't clarify if this is a destructive operation, requires authentication, has side effects, or what the expected outcome is. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 function without unnecessary words. It's appropriately sized for a simple operation, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'unstocking' entails (e.g., removal from a list, toggling a state), potential errors, or return values, leaving the agent with incomplete context for a mutation 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?
The schema description coverage is 100%, with the parameter 'itemId' clearly documented as 'article ID'. The description doesn't add any extra meaning beyond this, but since the schema is comprehensive, a baseline score of 3 is appropriate as it doesn't need to compensate for 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 action ('unstock') and resource ('article'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'stock_item' or 'is_item_stocked' beyond the basic verb difference, missing explicit scope or relationship 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?
No guidance is provided on when to use this tool versus alternatives such as 'stock_item' or 'delete_item', nor does it mention prerequisites like requiring the item to be stocked first. The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'update' implies a mutation operation, the description doesn't address important behavioral aspects like required permissions, whether the update is reversible, rate limits, error conditions, or what happens to the existing comment content. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and wastes no space on redundant details.
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 insufficiently complete. It doesn't explain what the tool returns, what permissions are needed, or how it differs from similar update operations. Given the complexity of update operations and the lack of structured metadata, 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 schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional semantic information about the parameters beyond what's already in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('更新します' - update) and the resource ('コメント' - comment), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_item', which also performs updates but on a different 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 like 'update_item' or 'create_comment'. There's no mention of prerequisites, constraints, or typical usage scenarios beyond the basic action.
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 responsibility for behavioral disclosure. While 'update' implies a mutation operation, the description doesn't mention permission requirements, whether the update is reversible, what happens to unspecified fields, rate limits, or error conditions. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward update operation and gets directly to the point with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions, side effects, or error handling, nor does it explain what the tool returns. The agent would need to guess about important operational details.
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, providing clear documentation for all 5 parameters. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation without adding extra value. This is adequate but not exceptional.
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 ('update') and target resource ('existing article'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_comment' or explain what distinguishes article updates from comment updates, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_item' or 'update_comment'. It doesn't mention prerequisites (e.g., needing an existing itemId), appropriate contexts, or when other tools might be more suitable, leaving the agent with insufficient usage 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 the full burden of behavioral disclosure. It states the tool retrieves data (a read operation) but doesn't mention any behavioral traits like pagination behavior (implied by page/perPage parameters but not explained), rate limits, authentication requirements, or error conditions. For a tool with no 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 without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
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 (3 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral context, usage guidelines, and output details. Without annotations or an output schema, the agent must infer behavior from the description alone, which is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for userId, page, and perPage parameters. The description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain what 'followers' means in this context or how pagination works). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定されたユーザーのフォロワー一覧を取得します' (Get the list of followers for a specified user). It uses a specific verb (取得/retrieve) and resource (ユーザーのフォロワー/user's followers). However, it doesn't explicitly distinguish itself from sibling tools like get_user_followees or get_users, which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_user_followers over get_user_followees (which likely retrieves users the target user follows) or get_users (which might retrieve general user lists). There's no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks follow status, implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what the return value indicates (e.g., boolean or detailed response). 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, clear sentence in Japanese that directly states the tool's function without any fluff or redundancy. It's front-loaded with the core purpose, making it efficient and easy to parse. Every word earns its place, adhering perfectly to conciseness standards.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete. It explains what the tool does but lacks details on behavior, usage context, or output. While adequate for a simple check, it doesn't provide enough information for an agent to use it effectively in all scenarios, such as understanding authentication needs or interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'userId' parameter documented as 'ユーザーID' (user ID). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints. According to the rules, with high schema coverage (>80%), the baseline score is 3, which is appropriate here as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定されたユーザーをフォローしているかどうかを確認します' (Check if a specified user is being followed). It uses a specific verb ('確認します' - check/verify) and resource ('ユーザー' - user), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_user_followers' or 'get_user_followees', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare it to siblings like 'get_user_followers' (which might list followers), or specify use cases (e.g., checking follow status before performing an action). This leaves the agent with minimal context for 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 full burden. While it indicates this retrieves user details, it doesn't disclose what authentication is required, whether this is a read-only operation, what specific details are returned, or any rate limits/constraints. For a user information 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 with zero wasted 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?
Given this is a simple retrieval tool with 0 parameters and no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, it should ideally mention what authentication is required and what kind of user details are returned. The description is minimally adequate but has clear 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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description correctly doesn't mention any parameters, which is appropriate. Baseline for 0 parameters is 4, and the description doesn't add or detract from parameter understanding.
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 the resource ('認証されたユーザーの詳細情報' - authenticated user's detailed information). It distinguishes from siblings like 'get_user' which presumably gets any user, while this specifically gets the authenticated user. However, it doesn't explicitly contrast with 'get_user' which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used when you need information about the currently authenticated user, but doesn't explicitly state when to use this vs. 'get_user' (which likely requires a user ID parameter). There's no guidance about prerequisites (authentication required) or alternatives, leaving usage context somewhat implied rather than explicit.
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:

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

Score Badge

Copy to your README.md:

[![mcp-server-qiita MCP server](https://glama.ai/mcp/servers/Selenium39/mcp-server-qiita/badges/score.svg)](https://glama.ai/mcp/servers/Selenium39/mcp-server-qiita)

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/Selenium39/mcp-server-qiita'

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