BuildBetter

Official

by buildbetter-app

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between open-resource and read-resource (which is explicitly an alias), and between build-query, nl-query, and query-template, which all generate queries in different ways, potentially causing confusion. The other tools, like recent-conversation-with and search-extractions, are more clearly differentiated.
Naming Consistency3/5
The naming is mixed, with some tools using verb-noun patterns (e.g., list-types, run-query, validate-query) and others using noun-verb or hyphenated phrases (e.g., schema-overview, top-customer-issues, recent-conversation-with). While readable, the lack of a consistent convention across all tools reduces predictability.
Tool Count4/5
With 15 tools, the count is reasonable for a GraphQL and resource management server, covering query building, execution, validation, and data retrieval. It's slightly on the higher side but still well-scoped, as each tool serves a specific function without obvious redundancy beyond the alias.
Completeness4/5
The toolset covers core GraphQL operations (query building, execution, validation) and resource fetching, with additional utilities for conversation and extraction search. Minor gaps exist, such as no explicit tools for mutations or subscriptions in GraphQL, but agents can likely work around this given the available query-focused tools.
Average 3/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool builds a query string but doesn't clarify if this is a read-only operation, whether it validates inputs, what happens with invalid parameters, or if there are rate limits. For a tool with 4 parameters and no annotations, 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 a single, efficient sentence: 'Build a simple GraphQL query string for a specific type'. It's front-loaded with the core purpose, uses no unnecessary words, and every part earns its place by specifying key elements like 'GraphQL' and 'specific type'.
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 (4 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't address what the tool returns (e.g., a string, an object), error handling, or usage context relative to siblings. For a query-building tool with no output schema, more detail on behavioral outcomes is needed.
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 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, provide examples, or clarify semantics like how 'filter' structures depend on schema. With high schema coverage, the baseline is 3.
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: 'Build a simple GraphQL query string for a specific type'. It specifies the verb ('Build'), resource ('GraphQL query string'), and scope ('for a specific type'). However, it doesn't differentiate from siblings like 'run-query' or 'query-template', which appear related to query execution or templating.
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 sibling tools like 'run-query' (which likely executes queries) or 'query-template' (which might handle templates), leaving the agent to guess based on names alone. There are no explicit when-to-use or when-not-to-use instructions.
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 the tool returns field names but doesn't describe the return format (e.g., list, object), potential errors (e.g., if type doesn't exist), or any constraints like rate limits or permissions needed. This leaves significant gaps for an agent to understand how to handle the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits, leaving the agent with insufficient information to fully understand how to invoke and interpret results from this tool.
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 input schema has 100% description coverage, with the parameter 'typeName' documented as 'GraphQL type name'. The description adds minimal value by specifying it's for 'GraphQL type (object or input object)', which slightly clarifies the parameter's context but doesn't provide additional syntax or format details 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 the tool's purpose with a specific verb ('Return') and resource ('field names for a specified GraphQL type'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list-types' or 'schema-overview', which might also relate to GraphQL schema information.
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 'list-types' or 'schema-overview'. It mentions the tool works for 'GraphQL type (object or input object)', which gives some context, but lacks explicit when-to-use or when-not-to-use instructions compared to siblings.
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 of behavioral disclosure. It states the tool 'Get help' but doesn't clarify what form this help takes (e.g., documentation, examples, troubleshooting), whether it's interactive or static, or any limitations like response format or availability. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get help on using BuildBetter MCP effectively.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by conveying essential information efficiently.
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 lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the help output looks like (e.g., text, links, structured data), any behavioral traits, or how to interpret results. For a help tool in a complex MCP environment with many siblings, more context is needed to guide the agent adequately.
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 input schema has 100% description coverage, with the single parameter 'topic' documented as 'Optional specific topic to get help on.' The description doesn't add any meaning beyond this, such as examples of topics or how they're used. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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: 'Get help on using BuildBetter MCP effectively.' It specifies the verb ('Get help') and the resource/scope ('using BuildBetter MCP effectively'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'schema-overview' or 'recent-conversation-with', which might also provide guidance or information.
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 specific contexts, prerequisites, or exclusions, nor does it refer to sibling tools that might offer related help or documentation. This leaves the agent with no explicit usage instructions beyond the general purpose.
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 of behavioral disclosure. It states the tool generates a GraphQL query but doesn't explain how it works (e.g., accuracy, limitations, or output format). For a tool that performs a non-trivial transformation, this is a significant gap, as it doesn't disclose traits like potential errors or the nature of the generated query.
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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core function, making it easy to understand at a glance. This represents optimal conciseness with no wasted information.
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 of generating GraphQL queries from natural language, the description is incomplete. With no annotations, no output schema, and minimal behavioral details, it fails to provide enough context for effective use. The tool likely has nuances (e.g., query accuracy, schema dependencies) that aren't addressed, making it inadequate for the task's demands.
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 input schema has 100% description coverage, with the single parameter 'description' documented as 'Natural language description of what you want to query'. The tool description doesn't add any further meaning beyond this, such as examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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: 'Generate a GraphQL query from a natural language description.' It specifies the verb ('Generate'), resource ('GraphQL query'), and transformation source ('natural language description'). However, it doesn't distinguish this tool from sibling tools like 'build-query' or 'run-query', which might have overlapping functionality, preventing 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 siblings like 'build-query', 'run-query', and 'query-template', there's no indication of the specific context or prerequisites for using 'nl-query', such as whether it's for initial query construction or a specific use case. This lack of differentiation results in minimal 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool fetches static resources but doesn't describe what 'fetch' entails (e.g., returns content, metadata, or both), potential side effects, authentication needs, rate limits, or error handling. This leaves significant gaps for a tool that likely interacts with external resources.
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, efficient sentence that directly states the tool's purpose and key constraint. It is front-loaded with the core action and avoids any redundant or verbose phrasing.
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 lack of annotations and output schema, the description is insufficient for a tool that fetches resources. It doesn't explain what is returned (e.g., file content, structured data), how errors are handled, or any dependencies on other tools like 'ListResources'. This leaves the agent with incomplete operational context.
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 100%, with the single parameter 'uri' well-documented in the schema as requiring a match to ListResources. The description adds no additional semantic context beyond this, so it meets the baseline for high schema coverage without compensating value.
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 action ('Fetch') and resource type ('static resource'), and specifies the source of valid URIs ('returned from ListResources'). However, it doesn't distinguish this tool from its sibling 'read-resource', which appears to serve a similar function, preventing 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 minimal guidance by mentioning that URIs must come from 'ListResources', but offers no explicit advice on when to use this tool versus alternatives like 'read-resource' or other query-related siblings. There's no mention of prerequisites, error conditions, or typical use cases.
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 of behavioral disclosure. It mentions generating queries but fails to detail key traits: whether this is a read-only or mutating operation, what permissions are needed, how errors are handled, or the format of the generated query. For a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Generate a query from predefined templates for common tasks.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.
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 (2 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations. Without annotations or an output schema, the description should compensate by explaining more about what the tool returns or how it behaves, but it does not, leaving the agent with insufficient information.
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 does not add meaning beyond what the input schema provides. The schema has 100% description coverage, clearly documenting both parameters: 'template' (with examples like 'find-person') and 'parameters' (as an object depending on the template). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description offers no extra parameter insights.
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: 'Generate a query from predefined templates for common tasks.' It specifies the verb ('generate') and resource ('query from predefined templates'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'build-query' or 'run-query', which might have overlapping functionality, preventing 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 siblings like 'build-query', 'run-query', and 'nl-query', there is no indication of specific contexts, prerequisites, or exclusions for using this template-based approach. This lack of comparative guidance limits the agent's ability to select the right tool.
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 of behavioral disclosure. It states the tool finds conversations, implying a read operation, but doesn't cover critical aspects like permissions needed, rate limits, error handling, or what 'most recent' means (e.g., by timestamp). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does, making it easy to parse and understand quickly.
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 annotations, no output schema, and a tool that performs a search operation, the description is incomplete. It lacks details on return format (e.g., what data is included in conversations), error cases, or how 'most recent' is determined. For a tool with 2 parameters and no structured behavioral hints, more context is needed to be fully helpful.
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 100%, with clear descriptions for both parameters ('limit' and 'name'). The description adds minimal value beyond the schema, mentioning 'by name' which aligns with the 'name' parameter but doesn't provide additional context like name matching rules or default behavior for 'limit'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Find the most recent conversation with a specific person by name.' It specifies the verb ('find'), resource ('conversation'), and key constraint ('most recent' with a person by name). However, it doesn't explicitly differentiate from sibling tools like 'search-extractions' or 'topic-conversations,' which might have overlapping functionality, so it doesn't reach the highest 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. It doesn't mention prerequisites, exclusions, or compare to sibling tools such as 'search-extractions' or 'topic-conversations,' leaving the agent to infer usage context without explicit 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 of behavioral disclosure. It mentions searching with optional filters and limits, but doesn't cover important aspects like pagination behavior, rate limits, authentication requirements, error handling, or what constitutes an 'extraction/signal'. For a search tool with no annotations, this leaves significant gaps in understanding its operational traits.
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, efficient sentence that front-loads the core purpose ('search extractions by keyword/phrase') and briefly mentions optional features. There's no wasted language, and every word contributes to understanding the tool's function. It's appropriately sized for a search 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 complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'extractions/signals' are, how results are returned, or any behavioral constraints. The description alone is insufficient for an agent to fully understand how to use this tool effectively in context.
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 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'keyword/phrase' and 'extraction type filter', but doesn't provide additional context about parameter interactions or search semantics. With high schema coverage, the baseline score of 3 is appropriate.
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: searching extractions/signals by keyword/phrase with optional filtering. It specifies the verb ('search') and resource ('extractions/signals'), though it doesn't explicitly differentiate from sibling tools like 'find-fields' or 'query-template' which might have overlapping functionality. The description is specific but lacks sibling distinction.
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 'find-fields' or 'query-template' from the sibling list. It mentions optional filters but doesn't specify scenarios, prerequisites, or exclusions. Without context on how this differs from other search/query tools, usage is implied rather than explicitly defined.
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 of behavioral disclosure. It mentions the source ('extractions/signals') but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what format the returned issues take. For a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses minimal words to convey the essential action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex data (customer issues). It doesn't explain the return format, such as whether issues are ranked, include counts, or have structured fields. For a tool with no structured behavioral or output information, the description should provide more context to be fully helpful.
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 adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, with clear documentation for both 'days' and 'limit' parameters including defaults, the baseline score of 3 is appropriate. The description doesn't compensate but doesn't need to given the comprehensive 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 the tool's purpose with a specific verb ('Get') and resource ('most common customer issues'), specifying they come from 'extractions/signals'. However, it doesn't explicitly differentiate this tool from potential siblings like 'search-extractions' or 'topic-conversations', which might also deal with customer issues or extractions.
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 siblings like 'search-extractions', 'topic-conversations', and 'nl-query' that might overlap in functionality, there's no indication of specific use cases, prerequisites, or exclusions for 'top-customer-issues'.
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 of behavioral disclosure. It states the tool 'finds' conversations, implying a read-only operation, but doesn't specify whether it searches across all data, requires permissions, has rate limits, or returns structured results. This leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded with the core purpose, making it easy for an agent to parse quickly and accurately.
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 lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what constitutes a 'conversation', how results are formatted, or any behavioral constraints like search scope or performance. For a tool with two parameters and no structured safety hints, more context is needed to ensure reliable use.
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 input schema has 100% description coverage, with clear documentation for both parameters ('topic' and 'limit'). The description adds no additional semantic context beyond what the schema provides, such as examples of topics or how matching works. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 with a specific verb ('Find') and resource ('conversations discussing a specific topic'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search-extractions' or 'recent-conversation-with', which might also involve conversation retrieval, so it doesn't reach the highest 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 siblings like 'search-extractions' and 'recent-conversation-with' that might overlap in functionality, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
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 of behavioral disclosure. It states the tool retrieves a list, implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, response format, or what constitutes 'internal ones'. This leaves significant gaps for an agent to understand how to use it effectively.
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, efficient sentence that front-loads the core purpose ('Get a list of available GraphQL object types') and adds a clarifying constraint ('excluding internal ones'). There is zero waste, and every word earns its place.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list looks like (e.g., format, structure), what 'internal ones' means, or any behavioral context. For a tool with no structured data to rely on, this leaves the agent with insufficient information to use it correctly.
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 the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as there's nothing to compensate for.
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: 'Get a list of available GraphQL object types' with the specific scope 'excluding internal ones'. It uses a specific verb ('Get') and resource ('GraphQL object types'), but doesn't explicitly differentiate from sibling tools like 'schema-overview' or 'find-fields' 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'schema-overview' or 'find-fields' that might serve similar purposes, nor does it specify prerequisites or contexts where this tool is preferred.
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 only states it's an alias for fetching static resources, lacking details on permissions, rate limits, error handling, or what 'static' entails (e.g., read-only, immutable). This is inadequate for a tool with potential behavioral implications.
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, efficient sentence that front-loads key information (alias and purpose) with zero waste. It appropriately sized for a simple tool, making every word count without unnecessary elaboration.
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 simplicity (1 parameter, no output schema) and lack of annotations, the description is incomplete. It fails to explain what a 'static resource' is, how it differs from dynamic resources, or what the fetch operation returns, leaving gaps in understanding for the agent.
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 100%, so the input schema fully documents the 'uri' parameter. The description adds no additional meaning beyond implying the URI must be from 'ListResources', which is already hinted in the schema. This meets the baseline for high schema coverage without extra value.
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 fetching a static resource by URI, which is a specific verb+resource combination. However, it doesn't distinguish itself from its sibling 'open-resource' beyond calling itself an alias, missing an opportunity to clarify any functional differences or scope variations.
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 usage by referencing 'open-resource' as an alias, suggesting it should be used similarly, but provides no explicit guidance on when to choose this tool over 'open-resource' or other alternatives like 'list-types'. This leaves the agent to infer context without clear exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses 'read-only' behavior, indicating no mutations, but lacks details on permissions, rate limits, error handling, or response format. This is a minimal but adequate disclosure for a read operation.
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, efficient sentence with zero waste—'Execute a read-only GraphQL query'—front-loaded with the core action. It's appropriately sized for the tool's purpose without unnecessary elaboration.
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 no annotations, 100% schema coverage, and no output schema, the description is minimally complete. It covers the read-only nature but lacks context on when to use versus siblings or behavioral details like response structure, making it adequate but with clear gaps.
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 100%, with clear documentation for 'query' and 'variables'. The description adds no additional meaning beyond the schema, such as query syntax or variable usage examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 'Execute a read-only GraphQL query' clearly states the verb ('execute') and resource ('GraphQL query'), with 'read-only' specifying the operation type. However, it doesn't differentiate from sibling tools like 'validate-query' or 'nl-query', which might also involve GraphQL queries, so it lacks sibling distinction.
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 siblings like 'validate-query' and 'nl-query' that likely handle GraphQL queries differently, there's no indication of context, prerequisites, or exclusions, leaving usage unclear.
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 the tool checks validity but doesn't describe what 'valid' means (e.g., syntax, schema compliance), potential error outputs, or performance aspects like rate limits. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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, efficient sentence that front-loads the core purpose ('Check if a GraphQL query is valid') and adds context ('before executing it') without any wasted words. Every part earns its place by clarifying the tool's role in a workflow.
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 (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on validation criteria, error handling, or integration with siblings like 'run-query,' which would enhance completeness for a validation tool in this context.
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 input schema has 100% description coverage, with the 'query' parameter clearly documented as 'The GraphQL query to validate.' The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with a specific verb ('Check') and resource ('GraphQL query'), and distinguishes it from siblings like 'run-query' by focusing on validation rather than execution. However, it doesn't explicitly differentiate from all siblings (e.g., 'build-query' or 'find-fields'), which keeps it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'before executing it,' suggesting this tool should be used prior to 'run-query' for validation. However, it lacks explicit guidance on when not to use it or alternatives for similar tasks, such as using 'build-query' for constructing queries instead of validating them.
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. It states the tool returns a markdown cheat-sheet but does not disclose behavioral traits such as performance characteristics, error handling, or whether it requires specific permissions. The description is minimal and lacks operational context.
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, efficient sentence that front-loads the key action and output. Every word earns its place, with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is adequate for a simple read-only tool but lacks depth. It explains what the tool does but not how it behaves or what the output entails, leaving gaps in contextual understanding.
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%, so no parameter documentation is needed. The description does not add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it avoids confusion.
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 states the verb ('Return') and resource ('markdown cheat-sheet describing key schema relationships'), specifying the output format and content. It distinguishes from siblings like 'list-types' or 'find-fields' by focusing on relationships and visual representation (mermaid diagram).
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 explicit guidance on when to use this tool versus alternatives like 'list-types' or 'help' is provided. The description implies usage for understanding schema relationships but lacks context on prerequisites, timing, or exclusions.
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:

[![BuildBetter-MCP MCP server](https://glama.ai/mcp/servers/buildbetter-app/BuildBetter-MCP/badges/card.svg)](https://glama.ai/mcp/servers/buildbetter-app/BuildBetter-MCP)

Score Badge

Copy to your README.md:

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

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