Allows AI agents to manage LINE Official Accounts via the Messaging API, providing capabilities to send broadcast, push, and multicast messages, manage rich menus, and retrieve account information, follower counts, and delivery statistics.
Premium MCP server that lets AI agents manage LINE Official Accounts.
Users type natural language in Claude / ChatGPT / Cursor → LineWhiz calls the LINE Messaging API.
Tool | Tier | Description |
| Free | Get LINE OA info: name, plan, picture |
| Free | Get follower count on a specific date |
| Free | Get remaining message quota this month |
| Pro | Send message to ALL friends |
| Pro | Send DM to a specific user |
| Pro | Send message to multiple users (max 500) |
| Pro | Get delivery stats for a date |
| Pro | Get user's display name, picture, etc. |
| Pro | List all rich menus for this LINE OA |
Related MCP server: nworks
Python 3.11+
uv package manager
LINE Messaging API channel (create one here)
# Clone and install
cd linewhiz && uv sync
# Configure environment
cp .env.example .env
# Edit .env → fill in LINE_CHANNEL_ACCESS_TOKEN and LINE_CHANNEL_SECRET
# Run the server
uv run src/server.py
# Test with MCP Inspector
mcp dev src/server.py
# Run tests
uv run pytestAdd to your MCP client config (e.g., Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"linewhiz": {
"command": "uv",
"args": ["run", "src/server.py"],
"cwd": "/path/to/linewhiz",
"env": {
"LINE_CHANNEL_ACCESS_TOKEN": "your_token_here",
"LINE_CHANNEL_SECRET": "your_secret_here",
"LINEWHIZ_TIER": "pro"
}
}
}
}linewhiz/
├── CLAUDE.md # AI coding spec (single source of truth)
├── pyproject.toml
├── Dockerfile
├── docker-compose.yml
├── .env.example
├── src/
│ ├── server.py # MCP entry point + tool registration
│ ├── config.py # Env config via pydantic Settings
│ ├── auth/
│ │ ├── api_keys.py # Key validation (SHA-256)
│ │ └── tiers.py # Free/Pro/Business gating + rate limits
│ ├── tools/
│ │ ├── account.py # get_account_info, get_friend_count, get_message_quota
│ │ ├── messaging.py # send_broadcast, send_push, send_multicast
│ │ ├── richmenu.py # list/create/set/link rich menus
│ │ ├── insights.py # get_message_stats, get_user_profile
│ │ ├── automation.py # [future] auto-reply
│ │ └── reporting.py # [future] weekly report
│ ├── services/
│ │ ├── line_api.py # Async LINE API wrapper
│ │ └── flex_builder.py
│ ├── models/
│ │ ├── user.py # API key + tier models
│ │ └── usage.py # Usage log model
│ └── db/
│ └── database.py # SQLite async init + migrations
├── tests/
│ ├── conftest.py
│ ├── test_account.py
│ ├── test_messaging.py
│ ├── test_richmenu.py
│ └── test_auth.py
└── docs/Tier | Price | Daily Calls | Tools |
Free | $0/mo | 100 | Account info, friend count, quota |
Pro | $15/mo | 5,000 | + Messaging, rich menus, insights |
Business | $45/mo | Unlimited | All tools |
# Build and run
docker compose up --build
# Or build manually
docker build -t linewhiz .
docker run --env-file .env linewhiz# Install with dev dependencies
uv sync --all-extras
# Lint
uv run ruff check src/ tests/
# Type check
uv run mypy src/
# Test
uv run pytest -vMIT
Get LINE Official Account info: name, friend count, plan, picture URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether the data is cached. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists the retrieved info without unnecessary words. Every part earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate by stating what info is retrieved. However, it lacks details on authentication, error handling, or output format, which could be important for an agent to use it correctly in context with siblings like 'get_user_profile'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description adds value by specifying the types of account info retrieved (name, friend count, plan, picture URL), which clarifies the output semantics beyond what the schema provides, though it doesn't detail format or structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('LINE Official Account info'), specifying what information is retrieved (name, friend count, plan, picture URL). It distinguishes from some siblings like 'get_followers' or 'get_friend_count' by covering multiple account attributes, but doesn't explicitly differentiate from all potential overlaps like 'get_user_profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, context, or exclusions, such as whether it's for the authenticated account only or if it requires specific permissions. 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.
Get the list of user IDs of followers of this LINE OA. Use this to find user IDs for send_push_message or get_user_profile.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of user IDs to return (default 300, max 1000) |
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 explains the tool's purpose and downstream use cases but lacks details on rate limits, authentication requirements, pagination behavior, or error conditions that would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the tool's purpose, and the second provides usage context. It's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one documented parameter and no output schema, the description is adequate but minimal. It explains what the tool does and why to use it, but lacks details about return format, error handling, or system constraints that would provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'limit' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the list of user IDs of followers') and resource ('this LINE OA'), distinguishing it from siblings like get_friend_count or get_user_profile by focusing on follower retrieval rather than friend relationships or individual profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to find user IDs for send_push_message or get_user_profile'), but it doesn't explicitly state when not to use it or mention alternatives like get_friend_count for different relationship types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of LINE OA friends/followers on a specific date. Provide date as YYYYMMDD or omit for yesterday.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYYMMDD format. Defaults to yesterday. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the date parameter and default behavior but lacks details on permissions needed, rate limits, error conditions, or what the return value looks like (e.g., integer count, JSON structure). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides parameter guidance. It is front-loaded with the core functionality and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 optional parameter) and high schema coverage, the description is adequate but incomplete. It lacks output details (no output schema) and behavioral context (no annotations), which are needed for full understanding. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'date' parameter fully. The description adds minimal value by restating the format (YYYYMMDD) and default (yesterday), which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the number') and resource ('LINE OA friends/followers') with precise scope ('on a specific date'). It distinguishes from siblings like 'get_followers' (likely listing individuals) by focusing on count retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (to obtain follower count on a date) and includes a default behavior (yesterday if omitted). However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'get_account_info' which might include similar data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get delivery statistics (sent, opened, clicked) for messages sent on a specific date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYYMMDD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but doesn't specify permissions needed, rate limits, data freshness, or output format. This leaves gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get delivery statistics') and specifies key details (metrics and date scope) without unnecessary words. Every element earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving analytics with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameter scope but lacks details on behavioral traits, usage context, and output expectations, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'date' parameter fully documented in the schema as 'Date in YYYYMMDD format'. The description adds no additional parameter semantics beyond what the schema provides, such as date range constraints or format examples, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('delivery statistics for messages'), specifying what metrics are retrieved (sent, opened, clicked) and the scope (messages sent on a specific date). It distinguishes itself from siblings like 'get_account_info' or 'send_broadcast' by focusing on message analytics, though it doesn't explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as whether it's for historical analysis or real-time monitoring, or if other tools like 'get_message_quota' might be related. It mentions a specific date requirement but lacks context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining message quota for this month. Shows total allowed, used, and remaining messages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a read-only operation (implied by 'Get'), returns structured quota data (total, used, remaining), and is time-bound ('for this month'). It doesn't mention rate limits, authentication needs, or error conditions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the core purpose, and the second elaborates on the output details. It's front-loaded and efficiently structured, with every sentence adding essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is nearly complete: it explains what the tool does and what data it returns. It could improve by mentioning if the quota resets monthly or any prerequisites, but for a simple read tool, it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the tool's purpose and output. This meets the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get remaining message quota') and resource ('for this month'), with precise scope details ('Shows total allowed, used, and remaining messages'). It distinguishes itself from sibling tools like get_message_delivery_stats by focusing on quota metrics rather than delivery performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'for this month' and the data it returns, suggesting it's for monitoring usage limits. However, it doesn't explicitly state when to use this tool versus alternatives like get_account_info (which might include quota data) or when not to use it (e.g., for real-time delivery tracking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profile info of a LINE user: display name, picture, status message.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | LINE user ID (starts with U, 33 chars) |
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 what data is retrieved but doesn't mention permissions needed, rate limits, error handling, or response format. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists the retrieved data clearly. There is no wasted language, and it's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers what data is returned but lacks behavioral context like permissions or error handling. Without annotations or output schema, it should do more to compensate, but it meets a basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'user_id' parameter fully. The description doesn't add any parameter-specific details beyond what's in the schema, such as examples or constraints. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('profile info of a LINE user'), specifying what data is retrieved (display name, picture, status message). It distinguishes from siblings like 'get_account_info' by focusing on user profiles rather than account details, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_account_info' or 'get_followers'. The description implies it's for retrieving user profile data but offers no context about prerequisites, limitations, or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message to ALL friends of this LINE OA. Use carefully — this reaches everyone and costs message quota.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Text message to broadcast (max 5000 chars) |
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 effectively adds context beyond the schema by warning about reaching 'everyone' and costing 'message quota,' which are critical behavioral traits for a broadcast tool. It does not fully detail aspects like rate limits or error handling, but provides substantial value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that convey the purpose and critical warnings without any wasted words. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a broadcast operation with cost implications), no annotations, and no output schema, the description does well by covering purpose, scope, and key warnings. However, it could be more complete by mentioning potential side effects or response formats, but it is largely adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'message' documented as 'Text message to broadcast (max 5000 chars).' The description does not add any additional meaning beyond this, such as formatting or content guidelines, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Send a text message') and target resource ('ALL friends of this LINE OA'), distinguishing it from siblings like send_multicast or send_push_message. It precisely defines the scope and verb without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the warning 'Use carefully — this reaches everyone and costs message quota,' indicating when to exercise caution. However, it does not explicitly state when to use this tool versus alternatives like send_multicast or send_push_message, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message to multiple users at once (max 500 user IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| user_ids | Yes | List of LINE user IDs (max 500) | |
| message | Yes | Text message to send (max 5000 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('send') implying a write operation, but does not cover critical aspects like authentication needs, rate limits, delivery guarantees, costs, or response format. The constraint (max 500 users) is useful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a key constraint. There is no wasted text, and it is appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context, and output expectations, which are essential for an agent to invoke it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('user_ids' and 'message') with their types and constraints. The description adds no additional semantic meaning beyond what the schema provides, such as format details or usage examples, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('send a text message'), target ('to multiple users at once'), and constraint ('max 500 user IDs'), making the purpose immediately understandable. It distinguishes from siblings like 'send_broadcast' by specifying 'multiple users' rather than a broadcast mechanism, though the exact differentiation isn't explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'send_broadcast' or 'send_push_message', nor does it mention prerequisites, user eligibility, or context for sending messages. It states a constraint (max 500 users) but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a direct text message to a specific user by their LINE user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | LINE user ID (starts with U, 33 chars) | |
| message | Yes | Text message to send (max 5000 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool sends a message but does not disclose behavioral traits such as authentication requirements, rate limits, delivery confirmation, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core purpose. There is no wasted text, and every word contributes directly to clarifying the tool's function, 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.
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 and no output schema), the description is adequate but incomplete. It covers the basic purpose and parameters via the schema, but lacks details on behavioral aspects like response format, errors, or side effects, which are important for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description does not add any meaning beyond what the schema provides, such as explaining the LINE user ID format or message constraints in more detail. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send a direct text message'), specifies the resource ('to a specific user'), and distinguishes from siblings like 'send_broadcast' and 'send_multicast' by emphasizing 'direct' and 'specific user'. It provides a complete, unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for direct messaging to individual users, but does not explicitly state when to use this tool versus alternatives like 'send_broadcast' or 'send_multicast'. It lacks explicit guidance on prerequisites or exclusions, leaving usage context somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_account_infoget_followersget_friend_countget_message_delivery_statsget_message_quotaget_user_profilelist_rich_menussend_broadcastsend_multicastsend_push_messageEach tool has a clearly distinct purpose targeting specific LINE Official Account operations. For example, get_followers retrieves user IDs, get_friend_count provides counts, and send_* tools handle different message delivery methods with clear boundaries. No tools appear to overlap or cause confusion.
All tools follow a consistent verb_noun naming pattern using snake_case throughout. Examples include get_account_info, send_broadcast, and list_rich_menus, with no deviations in style or convention.
With 10 tools, the set is well-scoped for managing a LINE Official Account, covering account info, user data, messaging, and analytics. Each tool earns its place without feeling excessive or insufficient for the domain.
The tools provide strong coverage for core LINE OA workflows, including account management, user profiling, and message sending. A minor gap exists in operations like updating or deleting rich menus, but agents can work around this with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kinzen-dev/LineWhiz'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
