bettermode
Server Details
Read Bettermode community spaces, members and posts; full-text search across your community.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- m190/usefulapi-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 8 of 8 tools scored.
Each tool targets a distinct resource or action: member, network, post, space, members listing, posts listing, spaces listing, and search. No overlap in functionality.
All tools follow a consistent 'verb_noun' pattern with the 'bettermode_' prefix: get/list/search plus resource name. No naming style mixing.
8 tools cover the core read operations for a community platform (members, posts, spaces, network, search) without redundancy. Well-scoped.
Only read operations (get, list, search) are provided. Missing create, update, delete for any resource, which are typical for a community management domain. Significant gaps.
Available Tools
8 toolsbettermode_get_memberGet memberARead-onlyInspect
Get a single community member by their id. Returns name, username, email, status, creation date, role, and tagline. Bettermode GraphQL query: member.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The member's id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds value by listing the specific fields returned (name, username, email, status, etc.), which exceeds what annotations offer.
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 concise with one main sentence and a supplementary note about the GraphQL query. It is front-loaded with the essential action, though the note could be omitted without loss.
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 get-by-id tool, the description covers the purpose, input, and return fields. It lacks details on error handling or missing IDs, but given the simplicity and annotations, it is reasonably complete.
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 coverage is 100% with a clear description of the 'id' parameter. The description merely restates 'by their id' without adding new meaning or usage details, so baseline score of 3 is appropriate.
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 gets a single community member by id, lists specific return fields, and distinguishes from siblings like 'bettermode_list_members' which lists multiple members.
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 indicates when to use (when you have a member id) but does not explicitly mention alternatives or when not to use. However, the purpose is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_get_networkGet networkARead-onlyInspect
Get top-level info about the Bettermode community ("network") this token belongs to — id, name, primary domain/subdomain, status, creation date, and total member count. No arguments. Bettermode GraphQL query: network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming a safe read operation. The description adds context by listing returned fields and mentioning it's a GraphQL query, which provides behavioral insight beyond the annotation. No contradictions.
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 consists of two succinct sentences with no redundant information. The first sentence describes output, the second clarifies no inputs and the underlying query. Every word earns its place.
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 parameterless, read-only tool, the description covers all necessary context: what it returns, that it requires no input, and it belongs to the token's network. No output schema exists, but the listed fields suffice.
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?
There are no parameters, and the description explicitly states 'No arguments,' which adds clarity beyond the empty schema. This fully communicates input requirements.
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 retrieves top-level info about the Bettermode community (network) and lists specific fields (id, name, domain, status, creation date, member count). It is distinct from sibling tools that focus on members, posts, or spaces.
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 tells when to use the tool (when basic network info is needed) and explicitly notes 'No arguments,' providing clear usage guidance. It does not explicitly state when not to use it, but the lack of alternatives is acceptable given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_get_postGet postARead-onlyInspect
Get a single post by its id. Returns title, shortContent, creation date, space, owner (member), and reaction/reply counts. Bettermode GraphQL query: post.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint annotation, the description adds value by specifying returned fields. It doesn't contradict annotations. Some behavioral details like error handling or rate limits are missing, but for a simple read tool this is sufficient.
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?
Two concise sentences, front-loaded with the action and key details. No unnecessary words.
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 get-by-ID tool with no output schema, the description covers purpose, input, and return fields. Missing details about response format for errors, but adequate for typical 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 coverage is 100% for the single 'id' parameter. The description reiterates the parameter's role but adds no additional format or constraint information beyond the schema.
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 it retrieves a single post by ID and lists the fields returned. This distinguishes it from sibling tools like bettermode_list_posts (multiple) and bettermode_search (query-based).
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 use when you have a post ID, but does not explicitly state when to use versus alternatives like list or search, nor provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_get_spaceGet spaceARead-onlyInspect
Get a single space by its id OR its slug (provide exactly one). Returns the space's name, slug, description, type, creation date, and member/post counts. Bettermode GraphQL query: space.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The space's id. Provide this OR `slug`. | |
| slug | No | The space's URL slug. Provide this OR `id`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it uses a GraphQL query and lists return fields, providing useful behavioral context beyond annotations. No contradictions.
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?
A single, well-structured sentence that front-loads the purpose and includes all necessary details without redundancy.
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 get tool, the description covers all needed: how to identify the space, what the response contains, and constraints. No output schema, but return fields are enumerated, making it self-contained.
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 coverage is 100%, so both parameters are already well-described in the schema. The description adds the global constraint to provide exactly one of the two, which is not explicitly stated in the schema descriptions.
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', the resource 'space', the unique identifiers (id or slug), and the return fields. It distinguishes from sibling tools like list_spaces (which returns multiple) and other get tools for different resources.
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 specifies to provide exactly one of id or slug, which is a clear usage guideline. It does not explicitly state when to use this vs alternative tools, but the sibling context makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_list_membersList membersARead-onlyInspect
List members of the community, with pagination. Optionally filter by a search term (query, matches name/username/email), by role (roleIds), order (orderBy), and reverse. Returns edges[].node (with role) plus pageInfo and totalCount. Bettermode GraphQL query: members.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of members to return (1..100, default 10). | |
| query | No | Filter to members matching this search term (name/username/email). | |
| offset | No | Number of members to skip (offset-based pagination). | |
| orderBy | No | Order field (e.g. "createdAt", "name"). | |
| reverse | No | Reverse the sort order. | |
| roleIds | No | Filter to members holding any of these role ids. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation: it specifies the return structure (edges, node with role, pageInfo, totalCount) and mentions it's a GraphQL query. No contradictions.
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 concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value without fluff.
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 6 parameters, no output schema, and readOnly annotation, the description covers pagination, filtering, and return structure adequately. It is complete for a list tool.
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 already has 100% coverage with descriptions for all 6 parameters. The description adds marginal value by clarifying that the query matches name/username/email, but overall 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 tool lists members of the community, with pagination and filtering options. It uses a specific verb+resource combination ('List members') and distinguishes from siblings like 'bettermode_get_member'.
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 mentions pagination and optional filters, implying when to use (for listing/filtering). It does not explicitly state when not to use or alternative tools, but the context from sibling names provides enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_list_postsList postsARead-onlyInspect
List posts across the community, with pagination. Optionally scope to one or more spaces (spaceIds), order (orderBy, passed through as a plain string), and reverse. Returns edges[].node (title, shortContent, space, owner) plus pageInfo and totalCount. Bettermode GraphQL query: posts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of posts to return (1..100, default 10). | |
| offset | No | Number of posts to skip (offset-based pagination). | |
| orderBy | No | Order field, passed through as a plain string (e.g. "createdAt", "publishedAt"). | |
| reverse | No | Reverse the sort order. | |
| spaceIds | No | Restrict to posts in these space ids. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations specify readOnlyHint=true, and the description confirms it is a read operation. It details return structure (edges, pageInfo, totalCount) and notes orderBy is passed as a plain string, adding useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (67 words) and front-loaded with the core purpose. Every sentence adds value, with no redundancy.
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 no output schema, the description explains return values well. It covers pagination, optional filters, and the GraphQL source. Missing explicit permission/error info, but acceptable for a read-only list tool.
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 coverage is 100% with descriptions for all parameters. The description adds minimal extra meaning beyond the schema, such as mentioning the GraphQL query, but it does not significantly enhance parameter understanding.
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 lists posts across the community, with pagination and optional scoping to spaces and ordering. It distinguishes from sibling tools like bettermode_get_post (single post) and bettermode_list_spaces.
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 explains when to use it (listing posts) and how to scope/order, but does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_list_spacesList spacesARead-onlyInspect
List spaces (the containers for posts — e.g. discussions, Q&A, articles) in the community, with pagination. Optionally filter by name (query), order (orderBy, a SpaceListOrderByEnum value), and reverse the order. Returns edges[].node plus pageInfo and totalCount. Bettermode GraphQL query: spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of spaces to return (1..100, default 10). | |
| query | No | Filter to spaces matching this name/search term. | |
| offset | No | Number of spaces to skip (offset-based pagination). | |
| orderBy | No | Order field — a SpaceListOrderByEnum value (e.g. "createdAt", "name"). | |
| reverse | No | Reverse the sort order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint: true`. Description adds valuable behavioral context: pagination support, return structure (edges[].node, pageInfo, totalCount), and reference to the underlying GraphQL query.
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?
Concise two-sentence description. First sentence states core purpose; second details filters and return structure. No waste.
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?
Describes pagination, optional filters, and return fields despite no output schema. Missing enumeration of `SpaceListOrderByEnum` values, but otherwise complete for a list tool.
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 descriptions cover all 5 parameters with 100% coverage. Description adds minimal extra value by mentioning the `SpaceListOrderByEnum` type but does not enumerate possible values. Baseline 3 is appropriate.
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?
Clearly states it lists spaces (containers for posts) with pagination and optional filters. Differentiates from sibling tools like `bettermode_get_space` (single space) and `bettermode_list_posts` (different resource).
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?
Indicates optional filtering by name, orderBy, and reverse, making usage context clear. Does not explicitly mention when not to use or alternatives, but sibling list is available for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bettermode_searchSearchARead-onlyInspect
Full-text search across the community (members, spaces, posts, …). Provide a query term; results come back grouped by entity type, each hit with id, title, subtitle, content, url, and entityId. Bettermode GraphQL query: search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Client-side cap on the number of hits per entity group (the SearchInput type has no server-side limit field). | |
| query | Yes | The search term. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the 'readOnlyHint' annotation by detailing the output structure (grouped by entity type with specific fields). No contradictions with annotations.
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, front-loaded with purpose, and provides necessary details without extraneous 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 no output schema, the description adequately explains the return format. It could mention pagination or the limit's effect, but overall sufficient for a simple search tool.
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 coverage is 100% with clear descriptions for both parameters. The description reiterates the 'query' parameter and adds context about result grouping, but does not significantly enhance understanding of the 'limit' parameter beyond the schema.
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 performs full-text search across multiple entity types (members, spaces, posts, etc.), which distinguishes it from the sibling tools that get or list specific entities. The verb 'search' and resource 'community' are 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 explains that a 'query' term is required and results are grouped by entity type. While it does not explicitly state when not to use or name alternatives, the context of sibling tools makes it clear that this is for cross-entity search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!