weflow-mcp

by L-Chris

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
The two message retrieval tools (weflow_get_messages and weflow_get_session_messages_chatlab) have overlapping purposes; the first already supports ChatLab format, making the second redundant and confusing. Other tools are distinct within their domains.
Naming Consistency3/5
Tool names use a consistent 'weflow_' prefix but mix verb_noun (list_sessions, get_messages), noun-only (health, request), and SNS category prefixes (sns_timeline, sns_export) inconsistently. The use of both 'list_' and 'get_' for similar actions adds inconsistency.
Tool Count5/5
12 tools is appropriate for a domain covering health, chat sessions, messages, contacts, group members, and Moments. The number is well within the expected range and each tool addresses a specific sub-area.
Completeness3/5
The server provides comprehensive read and export functionality for chat and Moments, but lacks dedicated tools for sending messages or managing contacts/groups. While weflow_request can fill some gaps, core operations like sending a message are not directly exposed.
Average 2.9/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only implies a read operation via 'Get' but does not disclose side effects, required permissions, or the behavior of the 'fast' parameter, leaving significant opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler, which is concise. However, it largely restates the tool name and omits critical details, making it under-specified rather than elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, no annotations, and no output schema, the description is the only source of context. It fails to explain what the statistics contain, what the tool returns, or what 'fast' does, rendering it incomplete even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes a single optional 'fast' parameter with a union of types but no description. The tool description does not mention 'fast' at all, and with 0% schema description coverage, the agent has no way to understand its meaning or how to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get WeFlow Moments export statistics' uses the specific verb 'Get' and identifies the resource as 'WeFlow Moments export statistics', clearly indicating the tool's function. It distinguishes from the sibling weflow_sns_export by focusing on statistics rather than the export itself, but 'statistics' remains 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?
The description provides no guidance on when to use this tool versus alternatives like weflow_sns_export or weflow_sns_timeline. There is no mention of prerequisites, timing, or how it fits into the export workflow.
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 for behavioral disclosure. It implies a read-only operation via 'Get', but does not mention pagination behavior, rate limiting, authentication requirements, or what constitutes a 'timeline entry'. No details about filtering, ordering, or response structure are given.
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, front-loaded sentence with no wasted words. It is concise, but it is under-specified rather than elegantly compact. It does not use bullets or structure, but that is acceptable given its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no output schema, and no annotations. The description is only 7 words long, providing no context about pagination, filtering options, return format, or integration with other tools. This is completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only 'usernames' has a description). The tool description adds no parameter semantics at all—it doesn't explain start/end, limit/offset, media filters, or keyword. With 9 parameters and minimal schema descriptions, the description should compensate but does not.
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 states a specific verb ('Get') and resource ('WeFlow Moments timeline entries'), which clearly indicates this tool retrieves timeline data. It distinguishes from siblings like weflow_sns_export (export) and weflow_sns_usernames (usernames), though 'Moments' could be ambiguous.
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?
There is no guidance on when to use this tool versus alternatives. No mention of filtering, pagination relationships, or scenarios that would favor this tool over weflow_sns_export or other sibling tools. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only mentions that actions map to endpoints, but does not explain whether install/uninstall are destructive, whether status is read-only, or any side effects. This is a significant gap for a tool that likely mutates state.
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, front-loaded sentence with no filler words. It is concise and clear, though slightly under-specified. It earns points for efficiency but not full marks due to lack of detail.
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 simple schema (1 param, no output schema) and no annotations, the description is still incomplete. It does not explain the meaning of 'anti-delete', the effects of each action, or any return values. The tool appears straightforward, but the description leaves too much to assume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the action values (status, install, uninstall) that are already in the schema enum, but does not explain what each action does or what the 'endpoints' imply. It adds minimal semantic value beyond 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 a specific resource ('WeFlow Moments anti-delete status') and a verb ('Manage'), and lists the three actions. It distinguishes from sibling tools by focusing on the anti-delete functionality, though it doesn't fully explain what 'anti-delete' entails.
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 vs alternatives, nor any context about choosing between status, install, or uninstall. The action enum implies some usage, but the description does not explicitly state any use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'lists' sessions, implying a read-only operation, but does not disclose details like pagination, default behavior for the limit parameter, or whether the search is case-insensitive. There is no mention of side effects, error conditions, or return format specifics, which is a notable gap given the absence of annotations.
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 exceptionally concise: two sentences, front-loaded with the primary action. Every word earns its place, with no fluff or redundancy. This is a model of efficient structure.
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 optional parameters, no output schema, and no annotations, the description is too sparse. It does not specify what 'sessions' contains, how 'limit' behaves, the difference between 'json' and 'chatlab' formats, or return value structure. It also fails to connect to sibling tools (e.g., when to use get_session_messages_chatlab). The description provides the minimum viable purpose but lacks the completeness needed for an agent to fully understand the tool's role and invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for all three parameters. It only explains 'keyword' ('search username or display name'), which is one of three. 'limit' and 'format' are not mentioned at all, leaving their semantics unclear. This is insufficient for a 3-parameter tool with no schema 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 function: 'List WeFlow chat sessions' with a specific verb and resource. It also mentions a keyword search capability, distinguishing it from sibling tools like weflow_get_messages or weflow_list_contacts. However, it lacks a more explicit scope or exclusion, so it's not quite 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 minimal guidance on when to use this tool. 'Use keyword to search username or display name' gives a hint about parameter usage, but there is no explicit when-to-use vs alternatives, nor any exclusions or comparisons to sibling tools like weflow_list_contacts or weflow_get_session_messages_chatlab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects like overwriting files, the range of parameters (media export, filtering), or any prerequisites. The single sentence provides only the core action without behavioral details.
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 one sentence with no filler, front-loaded with the key action. However, it might be too sparse for a tool with 10 parameters, but as a concise statement it is 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 (10 parameters, no output schema, no annotations), the description is insufficiently complete. It does not address return values, parameter behavior, or how this export relates to sibling export tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the 10 parameters. It only mentions the general action, leaving outputDir, filters, and export options unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Export' and identifies the resource ('WeFlow Moments'), destination ('local directory'), and source ('WeFlow app process'). This clearly distinguishes it from sibling tools like weflow_sns_export_stats, which handles statistics rather than the export itself.
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 such as weflow_sns_timeline or weflow_sns_export_stats. The description implies usage through the name but does not state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It provides only a high-level summary of features and does not mention pagination behavior (limit/offset), error handling, authentication requirements, or safety implications. The tool is read-only in nature, but the description lacks important context about how results are returned or what media export entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word earns its place. It efficiently communicates the key capabilities without unnecessary fluff.
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 (13 parameters, no output schema, no annotations), the description is too minimal. It does not cover return format details, pagination behavior, how ChatLab format differs from JSON, or how this tool relates to sibling weflow_get_session_messages_chatlab. The agent would likely need additional investigation 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 only 8%, so the description must compensate. It adds semantic meaning by grouping several parameters into features: 'date ranges' implies start/end, 'keyword filtering' implies keyword, 'ChatLab format' implies format=chatlab, and 'media export flags' implies image/video/voice/emoji/media. However, it does not explain talker, limit, offset, or the full format enum, leaving many parameters underspecified.
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 uses a specific verb ('Get') and resource ('messages from one WeFlow session by talker ID'), clearly indicating the tool's scope. It also lists supported features (date ranges, keyword filtering, ChatLab format, media export flags) but does not explicitly differentiate from the sibling tool weflow_get_session_messages_chatlab, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. While it implies usage for retrieving messages from a session with various options, it does not mention exclusions or name sibling tools for comparison, leaving the agent to infer the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the endpoint and ChatLab format, which are useful, but it does not explain pagination behavior, ordering, or the nature of 'ChatLab format'. It also does not explicitly state that the operation is read-only (though 'pull' implies it) or how the optional parameters affect results.
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, front-loaded sentence that immediately states the action, resource, format, and endpoint. It avoids unnecessary words and is efficient. However, its brevity leaves other dimensions under-covered, but as a concise statement it meets the bar.
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?
The tool has five parameters, no output schema, and no annotations. The description is too terse to fully contextualize usage: it fails to explain optional filtering parameters, the definition of 'ChatLab format', or how results are returned. An agent would have to guess from the endpoint name, which is risky for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'id' is described). The description does not mention any of the four optional parameters (end, limit, since, offset) or their semantics. With the majority of parameters undocumented and no compensating explanation, an agent has insufficient information to correctly invoke the tool beyond providing the required ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pull' and clearly identifies the resource as 'one session' with a defined output format ('ChatLab format') and a concrete endpoint. This differentiates it from sibling tools like weflow_list_sessions (which lists sessions) and weflow_get_messages (likely a general message query), making the purpose unambiguous.
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 tool is for retrieving messages from a single session in ChatLab format, but it does not explicitly state when to use it over alternatives such as weflow_get_messages or weflow_list_sessions. There is no mention of exclusions or direct comparison to sibling tools, leaving usage context 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.
Behavior1/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 merely states 'Call a custom WeFlow API endpoint' without mentioning side effects, authentication requirements, rate limits, or error behavior. For a generic request tool, this is a severe 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, focused sentence with no redundancy or fluff. It efficiently communicates both purpose and usage guidance, earning its place without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, no output schema, and no annotation context, the description is only one sentence. It fails to explain endpoint structure, authentication semantics, response format, or any operational details, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description adds no parameter-level guidance. The agent receives no explanation of how to construct 'path', format 'body' or 'query', or interpret the 'authenticated' flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a generic API caller for custom WeFlow endpoints, explicitly differentiating from dedicated sibling tools with 'Use this for endpoints not covered by dedicated tools.' The verb 'Call' and resource 'custom WeFlow API endpoint' make the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this for endpoints not covered by dedicated tools.' It implies that dedicated tools should be used when available, but it doesn't enumerate specific alternatives or provide exclusion criteria beyond 'not covered.'
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 available, so the description must carry the burden of behavioral disclosure. It does not explicitly state the operation is read-only, nor does it explain the effect of forceRefresh (e.g., cache bypass and latency implications). It also omits return format and pagination behavior, leaving important behavioral traits undisclosed.
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 sentence with no filler, front-loading the action 'List' and the object. It is appropriately concise, though it could be expanded with essential details without harming 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?
With four parameters (including the unexplained forceRefresh and withCounts), no output schema, and no annotations, the tool requires more context than provided. The description fails to cover critical aspects like response structure, forceRefresh behavior, and when to choose this over other listing tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only chatroomId is described). The description's phrase 'optionally including message counts' hints at includeMessageCounts/withCounts, but it does not explain forceRefresh or the confusing relationship between withCounts and includeMessageCounts, both of which share the same $ref. The description adds minimal value beyond the schema for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('members of a WeChat group from WeFlow'), distinguishing it from sibling tools like weflow_list_contacts and weflow_get_messages. The optional 'including message counts' adds precise functional detail.
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. No exclusions or 'use this when' hints are given, and the sibling tools like weflow_list_contacts or weflow_list_sessions could overlap in unclear ways. The lack of contextual scenarios makes it insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but there is no mention of return format, pagination, authentication requirements, or any potential side effects. The description lacks transparency about what happens when invoked.
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, front-loaded sentence with no unnecessary words. Every word earns its place, and the structure is perfectly concise for a zero-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should explain return values and provide more context about what 'WeFlow Moments publishers' are. It does not specify what is returned (e.g., usernames, profiles, IDs), nor does it clarify the tool's role relative to the platform. The description is too minimal to be fully self-contained.
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 zero parameters, so the baseline is 4. The description does not need to add parameter meaning since there are none. The schema already confirms no properties, and the description aligns without conflicting.
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 uses a clear verb 'List' with a specific resource 'WeFlow Moments publishers'. It distinguishes from siblings like weflow_sns_timeline (which lists moments) and weflow_list_contacts by focusing on publishers. However, it does not elaborate on what exactly 'publishers' means or what the output contains, slightly limiting specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no mentions of ideal scenarios, exclusions, or comparisons with sibling tools. The description only states the action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't disclose return format, pagination, default limit, or other behavioral traits. The verb 'List' implies read-only but that's not explicit.
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?
Two concise sentences, front-loaded with purpose, and no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no annotations or output schema, the description is minimally adequate but lacks details about limit behavior and return shape.
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 explains that keyword searches specific fields, adding meaning beyond the bare schema. However, the limit parameter is not described at all, and with 0% schema coverage, the description should address both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists WeFlow contacts, a specific resource. The keyword search fields further clarify the scope, but it doesn't explicitly differentiate from sibling tools like weflow_list_sessions or weflow_get_group_members.
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?
Usage is implied: if you need to find contacts by username, nickname, remark, or display name, use this tool. However, no explicit when-to-use vs alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. The word 'check' implies a read-only operation, but the description does not specify the return value, error behavior, or whether it performs any network request beyond a simple ping. This leaves the agent guessing about the outcome.
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, focused sentence with no filler. It is front-loaded and easy to parse.
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 output schema and no annotations, the description should explain what the tool returns. It only states the check, leaving the output format unspecified. For a tool this simple, adding a return type or example would make it complete.
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 zero parameters, so the description adds no parameter-specific information. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly identifies the resource ('local WeFlow HTTP API reachability'). It is distinct from sibling tools that handle sessions, messages, contacts, and SNS operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's context clear: it is for verifying API reachability. While it doesn't explicitly exclude alternatives or mention when to use it, the purpose itself implies using it as a preliminary check before other WeFlow operations.
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:

[![weflow-mcp MCP server](https://glama.ai/mcp/servers/L-Chris/weflow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/L-Chris/weflow-mcp)

Score Badge

Copy to your README.md:

[![weflow-mcp MCP server](https://glama.ai/mcp/servers/L-Chris/weflow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/L-Chris/weflow-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/L-Chris/weflow-mcp'

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