WeWork MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: analyze_project_tasks focuses on task analysis, find_project_by_name and search_projects handle project discovery (though these two could be confused), get_project_details and get_project_statistics provide different project information, and test_connection is clearly separate. The main ambiguity is between find_project_by_name and search_projects, which both search projects by name with slightly different approaches.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern with clear verb_noun structure (analyze_project_tasks, find_project_by_name, get_project_details, etc.). The only minor deviation is test_connection, which uses a simpler verb_noun pattern but still fits the overall naming convention.
Tool Count5/5
With 6 tools, this is well-scoped for a project management server focused on WeWork. The count is appropriate as it covers core operations (project discovery, details, statistics, task analysis) without being overwhelming or too sparse for the domain.
Completeness3/5
The toolset covers project discovery and analysis well but has notable gaps in project lifecycle management. There are no tools for creating, updating, or deleting projects or tasks, which limits agents to read-only operations. However, for analysis and monitoring purposes, the existing tools provide reasonable coverage.
Average 3/5 across 6 of 6 tools scored.
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 is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 the full burden of behavioral disclosure. It states this is a statistics retrieval operation but doesn't mention whether it's read-only, requires specific permissions, has rate limits, or what format the statistics are returned in. The description is too minimal 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 appropriately concise with a clear purpose statement followed by Args and Returns sections. However, the Returns section 'Thống kê chi tiết về dự án' (Detailed statistics about the project) is somewhat redundant with the purpose statement and could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and minimal behavioral disclosure, the description is incomplete. It doesn't explain what kind of statistics are returned, how they're formatted, or any behavioral characteristics. The description should provide more context given the lack of structured metadata.
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 includes an 'Args' section that explains the single parameter 'project_id' as 'ID của dự án' (ID of the project). With only 1 parameter and 0% schema description coverage, this minimal explanation is sufficient to understand the parameter's purpose, earning a baseline 4 for single-parameter tools.
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 'Lấy thống kê tổng quan về dự án' (Get overview statistics about the project), which provides a basic verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_project_details' or 'analyze_project_tasks', leaving ambiguity about what specific statistics are provided versus other project-related tools.
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_project_details' or 'analyze_project_tasks'. The description only states what the tool does, not when it's appropriate or what distinguishes it from similar tools in the sibling list.
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 mentions that the tool can export a CSV file, which implies a file generation or download behavior, but doesn't specify where the CSV is saved, if it's returned as data, or any permissions/rate limits. This leaves significant gaps for a tool with potential side effects.
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 brief and structured with clear sections for Args and Returns, making it easy to scan. However, the first sentence 'Phân tích các tasks trong dự án' is somewhat redundant with the tool name and could be more specific to add value.
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 complexity of an analysis tool with 2 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks details on the analysis output format (beyond 'dictionary'), error handling, or integration with sibling tools, leaving room for improvement.
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 adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'project_id' is the ID of the project and 'export_csv' controls whether to export a CSV file with a default of False. This clarifies the purpose of each parameter, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analyzes tasks in a project' which provides a basic purpose, but it's vague about what specific analysis is performed (e.g., metrics, trends, completion rates). It doesn't clearly distinguish from siblings like 'get_project_statistics' which might overlap in functionality.
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_project_statistics' or 'get_project_details'. The description lacks context about prerequisites, such as needing an existing project, and doesn't mention when not to use it (e.g., for simple task listing vs. analysis).
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 mentions the similarity matching mechanism and default threshold, which is useful. However, it doesn't describe critical behaviors: whether this is a read-only operation, what happens if no matches are found, how similarity is calculated, performance characteristics, or error conditions. For a search 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and well-structured. It begins with a clear purpose statement, then uses labeled sections (Args, Returns) to organize parameter and return value information. Each sentence earns its place by providing essential information without redundancy. The bilingual presentation (Vietnamese/English) is efficient for parameter documentation.
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 (similarity-based search), no annotations, no output schema, and 2 parameters, the description is minimally adequate but has clear gaps. It covers the basic purpose and parameters well, but lacks information about return format, error handling, similarity algorithm details, and comparison with sibling tools. The absence of an output schema means the description should ideally explain what 'Thông tin dự án phù hợp nhất' (most suitable project information) contains, which it doesn't.
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 adds meaningful semantic context for both parameters beyond what the schema provides. For 'project_name', it explains this is 'Tên dự án cần tìm' (name of project to find). For 'threshold', it provides crucial context: 'Ngưỡng tương đồng tối thiểu' (minimum similarity threshold) with a default value. Given the schema has 0% description coverage, the description compensates well by explaining what each parameter means in the context of similarity matching.
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: 'Tìm dự án theo tên với độ tương đồng' (Find project by name with similarity). This specifies the verb (find), resource (project), and key mechanism (similarity matching). It distinguishes from siblings like 'get_project_details' (which likely retrieves specific project data) and 'search_projects' (which may have broader search capabilities), though the differentiation isn't explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'search_projects' or 'get_project_details', nor does it specify prerequisites or exclusions. The only implied usage is for finding projects by name with similarity matching, but this is essentially restating the purpose rather than providing contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the tool returns a list of matching projects, it doesn't describe important behavioral aspects like whether this is a read-only operation, how results are sorted, what happens with empty searches, or any rate limits. For a search 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately concise. It uses clear sections (Args, Returns) with bullet-like formatting, presents essential information upfront, and avoids unnecessary elaboration. Every sentence serves a purpose, though the formatting could be slightly more polished.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameters but lacks important context about behavioral traits, usage guidelines relative to siblings, and output format details. The absence of an output schema means the description should ideally explain more about what 'Danh sách các dự án phù hợp' (List of matching projects) contains.
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 adds meaningful semantic context for both parameters beyond what the input schema provides. The schema has 0% description coverage, but the description explains that 'search_text' is 'Text để tìm kiếm trong tên dự án' (Text to search within project names) and 'limit' is 'Số lượng kết quả tối đa' (Maximum number of results) with a default value. This compensates well for the schema's lack of descriptions.
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: 'Tìm kiếm dự án theo tên' (Search projects by name). This is a specific verb+resource combination that indicates searching projects using name-based criteria. However, it doesn't explicitly differentiate from sibling tools like 'find_project_by_name' or 'analyze_project_tasks,' 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. With sibling tools like 'find_project_by_name' and 'analyze_project_tasks' available, there's no indication of when this search tool is preferred, what its limitations are, or any prerequisites for use. This leaves the agent without 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?
No annotations are provided, so the description carries the full burden. It states the tool tests a connection and returns connection status information, which covers basic behavior. However, it lacks details on what 'testing' entails (e.g., authentication checks, network pings), potential side effects, error handling, or rate limits. For a tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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 concise and front-loaded: the first sentence states the purpose clearly, and the second sentence describes the return value. There's no wasted text, and both sentences earn their place by providing essential information. It could be slightly improved by integrating the return info more seamlessly, but it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It explains what the tool does and what it returns, which is adequate for a simple diagnostic tool. However, without annotations or output schema, it could benefit from more detail on the return format (e.g., what 'connection status' includes) or error cases, leaving some contextual 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, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, as there are none to explain. This meets the baseline for tools with no parameters, as the description appropriately focuses on the tool's action and output without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test kết nối với WeWork API' (Test connection to WeWork API). It specifies the verb ('test') and resource ('connection to WeWork API'), making the action explicit. However, it doesn't differentiate from sibling tools, which are all project-related, so this distinction is inherent but not explicitly stated.
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 any prerequisites, context for testing connections, or how it relates to the sibling project tools. Usage is implied only by the purpose, with no 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.
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 this retrieves project details including basic information, which implies a read-only operation, but doesn't specify whether authentication is required, rate limits exist, what happens if the project_id doesn't exist, or the format of returned data. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured with clear sections for Args and Returns. Each sentence earns its place: the purpose statement, parameter explanation, and return value description. No wasted words or redundant 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 the tool's simple nature (single parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and documents the parameter, but doesn't provide enough context about behavioral aspects like error conditions, authentication requirements, or data format. For a basic read operation, this is the minimum viable description.
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 explicitly documents the single parameter 'project_id' with its purpose ('ID của dự án' - ID of the project), adding meaningful context beyond the schema which has 0% description coverage. Since there's only one parameter and the description fully explains it, this compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Lấy chi tiết của một dự án' (Get details of a project), which is a specific verb+resource combination. It distinguishes from siblings like 'analyze_project_tasks' or 'get_project_statistics' by focusing on basic project details rather than analysis or statistics. However, it doesn't explicitly differentiate from 'find_project_by_name' which might also retrieve project details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'find_project_by_name' (which might search by name instead of ID) or 'search_projects' (which might return multiple projects). There are no explicit when/when-not instructions or prerequisites for usage.
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:

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

Score Badge

Copy to your README.md:

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

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