Read Bettermode community spaces, members and posts; full-text search across your community.
Scored across 8 tools
Each tool targets a distinct resource and action: get vs list for members, posts, and spaces, a dedicated network info tool, and a cross-entity search. Search is clearly distinguished as full-text across all entity types, so no two tools overlap in purpose.
All tools use a consistent `bettermode_` prefix followed by snake_case verb_noun names (get_member, list_posts, get_space, etc.). The only verb-only name, `bettermode_search`, still fits the overall convention.
With 8 tools, the set is well-scoped and each tool earns its place, covering the main read operations for members, spaces, posts, the network, and search. There are no redundant or filler tools.
The surface is entirely read-only, with no create, update, or delete operations for posts, members, or spaces, and no dedicated reply/comment retrieval. These are notable gaps for a community platform MCP, even though the read-only query surface itself is internally consistent.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description usefully adds the exact return field set and the underlying GraphQL query name. It does not disclose behavior for a missing/invalid id (error vs. null) or any permission scoping, so it adds moderate rather than rich 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?
Three short sentences, front-loaded with the action and its scope, then return fields, then provenance. Every sentence carries information an agent can use, with no filler.
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 single-parameter read tool with no output schema, listing the returned fields effectively compensates for the missing return contract, and readOnlyHint covers safety. Only edge-case behavior (not found, unauthorized) is absent, a minor gap.
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?
Only one parameter exists and schema description coverage is 100%, so the schema already documents 'id' fully. The description repeats the id-based lookup without adding format, sourcing, or constraint details, making the baseline 3 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?
States a specific verb and resource (fetch one community member by id) and enumerates the returned fields, which makes the tool's output shape predictable. The word 'single' implicitly contrasts with the sibling bettermode_list_members, though no sibling is named explicitly, keeping it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'by their id' suggests you must already know the identifier, which distinguishes it from list/search tools. There is no explicit when-to-use or when-not-to-use guidance, nor a pointer to bettermode_list_members or bettermode_search as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds that the network is scoped to the authenticating token and names the underlying GraphQL query, but says nothing about failure modes (e.g. invalid token) or caching/rate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight passage: purpose first, returned fields second, argument expectation and underlying query last. Every clause carries information and nothing is padded.
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?
No output schema exists, but the description compensates by enumerating the returned fields (id, name, domain, status, creation date, member count). For a no-argument read tool this is 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?
There are zero parameters, and the description confirms 'No arguments,' which matches the empty input schema. Baseline for a 0-param tool is 4; there is nothing further to document.
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?
States a specific verb (Get) and resource (top-level info about the Bettermode community/network), then enumerates the exact fields returned. No sibling tool (get_member, get_post, get_space) covers this resource, so the distinction is immediately clear.
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?
Explicitly notes 'No arguments' and that the network is resolved from the calling token, which tells the agent this is a safe zero-input call. No exclusion guidance is provided, but no sibling overlaps this resource, so none is really required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered, but the description adds genuinely useful behavior beyond them by enumerating the returned fields (title, shortContent, creation date, space, owner, reaction/reply counts). This compensates for the absence of an output schema.
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?
Three short sentences, front-loaded with the core action and the return-value summary before the GraphQL mapping note. No wasted text, though the trailing query-name mapping is marginally useful.
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 one-parameter read tool with no output schema, the description covers the action, the identifier, and the shape of the response. Nothing essential to correct invocation is missing, though a note on error behavior for a missing id is absent.
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 is a single parameter with 100% schema description coverage, so the schema already documents `id` fully. The description only restates 'by its `id`' and adds no format or sourcing detail, matching the baseline for fully-covered schemas.
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?
States a specific verb+resource with scope ('a single post by its `id`'), which implicitly separates it from the list_posts sibling. It stops short of explicitly naming an alternative, so it is clear but not fully differentiating.
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?
Usage is only implied: an agent can infer to use this for one post and list_posts for many, but the description never states when to prefer this tool or any exclusions. No prerequisites or fetching conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the exactly-one-key constraint and enumerates the returned fields, but says nothing about error behavior for a missing/invalid id or slug, or whether the result can be empty.
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 sentences, front-loaded with the identifier constraint and followed by the return summary; no filler or restated title.
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?
There is no output schema, so the enumeration of returned fields (name, slug, description, type, creation date, member/post counts) usefully fills that gap, and the input contract is fully specified. Nothing an agent needs to call this correctly is missing.
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% and both properties already document the 'Provide this OR id/slug' rule, so the baseline would be 3. The description adds the mutual-exclusivity enforcement ('exactly one'), which sharpens the schema's softer 'OR' wording and prevents an agent from passing both.
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?
States a specific verb and resource ('Get a single space') and names the two lookup keys, which cleanly separates it from the sibling list_spaces. It even maps to the underlying Bettermode GraphQL query, so an agent can place it precisely.
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 gives an operational constraint ('provide exactly one' of id or slug), which implies the lookup scenario, but never states when to prefer this over list_spaces or search. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is covered, and the description adds meaningful behavioral detail by disclosing the return shape (edges[].node with role, pageInfo, totalCount). It also correctly notes offset-based pagination, though it doesn't cover rate limits or result-set caps.
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?
Compact and front-loaded: purpose first, then filters, then return shape. The trailing 'Bettermode GraphQL query: members.' is mildly redundant but harmless for agents mapping to the underlying API.
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?
With no output schema, the description steps up to document the response envelope (edges[].node, pageInfo, totalCount) and pagination model, which is exactly what's needed. Only minor gaps remain around permissions or total-count edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented (including the name/username/email match semantics for query). The description restates those filters but adds no syntax, default, or constraint information beyond the schema, so the baseline 3 applies.
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?
States a specific verb (List) and resource (members of the community) with scope (pagination, optional filters). It clearly differentiates from sibling list tools by naming the resource, though it never explicitly contrasts with bettermode_get_member for single-member retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the filter options (search, role, order, reverse) but gives no explicit when-to-use versus when-not, and does not route the agent to bettermode_get_member or bettermode_search. Guidance is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description goes further by disclosing the return shape (edges[].node with title, shortContent, space, owner, plus pageInfo and totalCount) and noting that orderBy is passed through as a plain string, which is a real behavioral quirk. It doesn't mention rate limits or auth, but it adds meaningful context beyond the annotation.
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?
Three dense sentences with no filler; the core purpose and pagination are front-loaded before the optional parameters and return shape. The parenthetical about orderBy is slightly awkward but earns its place by flagging pass-through behavior.
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?
With no output schema, the description carries the burden of describing results and does so (edges[].node fields, pageInfo, totalCount). Pagination via limit/offset is acknowledged. Only the lack of any sibling-routing guidance keeps it short of 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 description coverage is 100%, so the schema already documents all five parameters, making 3 the baseline. The description echoes spaceIds/orderBy/reverse and adds the useful note that orderBy is a plain pass-through string, but contributes little 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?
States a specific verb+resource ('List posts across the community') and adds scope details (pagination, optional space scoping) plus the underlying GraphQL query name. It does not explicitly name siblings like bettermode_get_post or bettermode_search, so the agent must infer the boundary rather than being told it, keeping this below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally scope to one or more spaces' and the ordering parameters, but never states when to choose this over bettermode_search or bettermode_get_post. There are no exclusions and no stated prerequisites, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered and the description does not contradict it. It adds real context beyond the annotations: pagination behavior, the return shape (edges[].node plus pageInfo and totalCount), and the underlying Bettermode GraphQL query name.
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?
Three sentences, front-loaded with the resource definition and pagination, followed by parameter hints and the return shape. Tight overall, though the enumeration of orderBy/reverse lightly duplicates schema content.
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 5-parameter, no-output-schema list tool this is close to complete: it explains the resource, pagination, filter/sort options, and the exact return envelope. The main missing element is guidance on when to reach for this versus sibling list/search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (limit, query, offset, orderBy, reverse) are already documented in the schema. The description restates query, orderBy (with the enum name) and reverse without adding syntax or format detail beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb ('List') and resource ('spaces'), and goes further by defining the domain concept ('the containers for posts — e.g. discussions, Q&A, articles'). This clearly separates it from bettermode_list_posts and from the singular bettermode_get_space, though it never names those siblings explicitly.
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 covers filtering and ordering parameters but gives no when-to-use guidance, no prerequisites, and no routing to alternatives such as bettermode_search or bettermode_list_posts. An agent must infer usage purely from the 'list' verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, so the description's added value is the result shape: results grouped by entity type, with each hit containing id, title, subtitle, content, url, and entityId. That is genuine behavioral context an agent needs to parse the response, though pagination/ordering across groups and the client-side-only nature of `limit` are left to the schema.
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?
Three tight sentences: the scope comes first, the required input second, the return shape last. Nothing is padded, and the parenthetical mapping hint adds traceability without wasting space.
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?
With no output schema, the description must carry the return contract and it largely does, naming the grouping and per-hit fields. It stops short of describing pagination across entity groups or result ordering, which an agent calling a grouped search would find useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with `query` and the client-side `limit` cap fully documented in the schema, so the baseline is 3. The description mentions only the `query` term and adds no syntax, matching rules, or format detail beyond what the schema already provides.
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?
States a specific verb and resource ('Full-text search across the community') and enumerates the entity types covered (members, spaces, posts). This clearly distinguishes it from the sibling get_* and list_* tools, which retrieve a single entity or an unfiltered list rather than matching on a query term.
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 the agent how to call it ('Provide a `query` term') but never states when to prefer it over bettermode_list_posts / bettermode_list_members or the get_* tools. Usage is implied by the word 'search' rather than stated as an explicit condition or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bettermode_get_member1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_get_network1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_get_post1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_get_space1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_list_members1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_list_posts1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_list_spaces1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_search1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"bettermode_get_memberbettermode_get_networkbettermode_get_postbettermode_get_spacebettermode_list_membersbettermode_list_postsbettermode_list_spacesbettermode_searchSearch public Reddit posts, browse subreddit feeds, and read posts, comments, and profiles.
Read spaces, collections, pages and content; search docs and manage GitBook organization spaces.
Query channels, search messages, and read threads, users and reactions in your Stream Chat app.
Search and read public data from X/Twitter, Reddit, YouTube, Instagram, TikTok, Facebook, Threads, Bluesky, Trustpilot, Amazon, Google Maps, news, forums and the web. 90+ read-only tools plus ready-made research playbooks (lead finding, brand monitoring, review mining). Hosted: connect with an API key; 50 free requests per endpoint each month.
Add one secure layer between your agents and this server.
