Boardgames
Server Details
Boardgames MCP — wraps Board Game Atlas API (public demo client_id, free)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-boardgames
- 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.2/5 across 12 of 12 tools scored.
The tool set mixes board game tools (search_games, get_game, hot_games) with a completely unrelated generic query system (ask_pipeworx, compare_entities, etc.), making it nearly impossible for an agent to disambiguate which tools to use for which purpose. The two domains are entirely separate, causing severe confusion.
Naming conventions are inconsistent: board game tools use snake_case (search_games, hot_games), while Pipeworx tools use a mix of camelCase (ask_pipeworx) and snake_case (compare_entities). There is no overarching pattern, making tool names unpredictable.
With 12 tools, the count itself is reasonable. However, only 3 are relevant to the stated 'Boardgames' purpose, while the other 9 are unrelated, making the set feel bloated and misaligned with the server name.
The board game coverage is minimal: only search, get, and hot games. Missing obvious operations like filtering by category, sorting, adding reviews, or user ratings. Meanwhile, the Pipeworx tools form a different, unrelated complete system, but that doesn't serve the board game domain.
Available Tools
13 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that Pipeworx picks the right tool, fills arguments, and returns the result, which explains its internal behavior beyond the schema. With no annotations, this is valuable context, though it could mention any limitations or errors.
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?
Very concise and front-loaded: first sentence states purpose, second explains behavior, third gives examples. Every sentence 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?
Given the simplicity (1 required param, no output schema), the description is nearly complete. It explains what the tool does and how to use it, though it could briefly mention possible limitations or that it returns text.
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 schema covers the single parameter 'question' with a clear description. The description adds usage examples but no additional parameter semantics 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?
The description clearly states the tool accepts plain English questions and returns answers by selecting the best data source. It distinguishes itself from siblings like search_games or discover_tools by emphasizing natural language and automatic tool selection.
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 says 'no need to browse tools or learn schemas — just describe what you need,' and provides concrete examples (trade deficit, adverse events, 10-K filing). This clarifies when to use this tool vs. other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_entitiesAInspect
Compare 2–5 entities side by side in one call. type="company": revenue, net income, cash, long-term debt from SEC EDGAR. type="drug": adverse-event report count, FDA approval count, active trial count. Returns paired data + pipeworx:// resource URIs. Replaces 8–15 sequential agent calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| values | Yes | For company: 2–5 tickers/CIKs (e.g., ["AAPL","MSFT"]). For drug: 2–5 names (e.g., ["ozempic","mounjaro"]). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses return of paired data and resource URIs, and notes efficiency (replaces 8-15 calls). However, it does not mention idempotency, data freshness, authorization, or side effects. Adequate but not comprehensive.
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: first states purpose, second explains per-type details, third notes output and benefit. Front-loaded, no wasted 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?
Covers main points: purpose, input format, data sources (SEC EDGAR, adverse events), and output (paired data + URIs). Lacks explicit output schema details, but for a comparison tool this is reasonable. Could mention pagination or limits.
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 both parameters (100% coverage), and description adds context: explains type enum values and gives examples for values per type (tickers vs. drug names). This enriches understanding beyond 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?
Description clearly states the tool compares 2–5 entities side by side, specifies data fields per type (company: revenue, net income, etc.; drug: adverse events, FDA approval, etc.), and distinguishes it from sequential calls. It is specific and distinct from siblings.
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?
Provides clear context for when to use (comparison of entities) and gives type-specific guidance. Implicitly contrasts with sequential calls but does not explicitly state when not to use or mention alternatives like resolve_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes behavior as search returning most relevant tools with names and descriptions. Does not mention potential side effects or auth needs, but for a search tool this is acceptable. Lacks detail on whether it mutates state, but implied read-only.
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, each serving a purpose: first states action, second describes returns, third gives usage guidance. No fluff. Information is front-loaded with the key purpose.
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 low parameter count (2), full schema coverage, no output schema, and no annotations, description is complete enough. It explains what the tool does and when to use it. Could mention that results include tool descriptions to aid selection, but that's already implied.
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 baseline is 3. Description adds value by explaining the query parameter as 'Natural language description' and gives examples, and mentions default and max for limit. This enhances understanding beyond the schema's basic 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?
Description clearly states verb 'Search' and resource 'Pipeworx tool catalog', specifying the tool returns relevant tools with names and descriptions. It distinguishes from siblings by indicating it is for finding tools among many, while siblings like search_games and get_game focus on games.
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 says 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task', providing clear when-to-use guidance. No explicit when-not-to-use, but the context of 500+ tools implies it's for initial discovery before using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entity_profileAInspect
Full profile of an entity across every relevant Pipeworx pack in one call. type="company": SEC filings (recent), latest revenue/income/cash from XBRL, USPTO patents (assignee match), recent news (GDELT), and LEI (GLEIF). Returns pipeworx:// citation URIs for everything. Replaces 10–15 sequential agent calls. For federal contracts call usa_recipient_profile directly (too slow to bundle).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today; person/place coming soon. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). Names not supported — use resolve_entity first if you only have a name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns pipeworx:// citation URIs and replaces 10-15 sequential calls, making efficiency clear. Warns about slowness for federal contracts. Lacks details on any destructive actions, but the tool is inherently read-only. No annotations provided, so description carries full burden, which it mostly fulfills.
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?
Four sentences, each dense with information. Opening sentence captures purpose immediately. No redundancy or filler. Highly efficient.
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 the complex output as 'pipeworx:// citation URIs for everything,' which gives a sense of the format. However, no output schema is provided, and the description could be more precise about the response structure. Still adequate for a bundling tool with clear data sources.
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 has 100% coverage with descriptive parameter descriptions. Description adds value by providing examples (ticker vs CIK), clarifying that only 'company' is supported, and noting that names require prior resolution. This enriches the schema info.
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 returns a full profile of an entity across multiple Pipeworx packs, listing specific data types (SEC filings, XBRL, patents, news, LEI). It distinguishes from sibling tools like resolve_entity and compare_entities by its comprehensive scope.
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?
Explicit guidance on when to use (for company profiles) and when not to (federal contracts, use usa_recipient_profile instead). Also advises using resolve_entity if only a name is available, and notes that only 'company' type is supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetAInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the action (delete) and that it operates by key, but does not disclose side effects (e.g., whether deletion is permanent, confirmation steps, or if it fails silently). Adequate but not rich.
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?
Single sentence, 5 words, zero waste. Front-loaded with action and resource. Perfectly concise.
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 only 1 required parameter, no output schema, and simple semantics, the description is sufficient for a straightforward delete operation. It lacks behavioral details but is complete for the tool's simplicity.
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% (key is described as 'Memory key to delete'). The description does not add new meaning beyond the schema; it restates the purpose. 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?
The description uses the verb 'Delete' and specifies the resource 'stored memory', with 'by key' clarifying the scope. It is clear and distinguishes from siblings like 'remember' (store) and 'recall' (retrieve).
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 does not explicitly state when to use this tool versus alternatives, but it is clear that this is for deletion while siblings like 'recall' and 'remember' are for retrieval and storage. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_gameAInspect
Get full details for a specific board game by ID (from search_games results). Returns name, year, players, playtime, description, rating, publisher, designer, and price.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Board Game Atlas game ID (e.g. "OIXt3DmJU0" for Catan) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Board Game Atlas game ID |
| url | Yes | Board Game Atlas URL for the game |
| msrp | Yes | Manufacturer suggested retail price |
| name | Yes | Game name |
| rank | Yes | Overall rank |
| price | Yes | Current price |
| min_age | Yes | Minimum recommended age |
| image_url | Yes | Full-size image URL |
| thumb_url | Yes | Thumbnail image URL |
| description | Yes | Preview of the game description |
| max_players | Yes | Maximum number of players |
| min_players | Yes | Minimum number of players |
| max_playtime | Yes | Maximum playtime in minutes |
| min_playtime | Yes | Minimum playtime in minutes |
| trending_rank | Yes | Trending rank |
| year_published | Yes | Year the game was published |
| num_user_ratings | Yes | Number of user ratings |
| primary_designer | Yes | Primary designer name |
| primary_publisher | Yes | Primary publisher name |
| average_user_rating | Yes | Average user rating |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns specific fields, which is helpful, but does not disclose whether it may return null values, how errors are handled (e.g., invalid ID), or any rate limits. This is adequate but not thorough.
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 each sentence adds value. No wasted 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?
Given the tool has one simple parameter and no output schema, the description sufficiently explains what is returned. It is complete enough for this low complexity 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%, so the parameter is already documented in the schema. The description does not add additional meaning beyond what the schema provides (e.g., format or validation rules), so 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?
The description clearly states the verb 'Get' and the resource 'full details for a specific board game', and specifies it uses a Board Game Atlas ID, which distinguishes it from sibling tools like search_games or hot_games.
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 when to use this tool (when you have a specific game ID), but does not explicitly state when not to use it or mention alternatives. Sibling tools like search_games could be mentioned for lookup by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hot_gamesAInspect
Get the most popular board games ranked by current buzz. Returns title, year, player count, playtime, rating, and rank. Use this to discover trending games.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1–100, default 10) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of trending games |
| games | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature (no side effects), but does not mention rate limits, caching, or pagination behavior. Returns specific fields but no output schema exists.
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: first states purpose and ordering, second lists returned fields. No unnecessary words, front-loaded with key action.
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, description covers key return fields and ordering. Parameter schema is complete. Could mention that result set is not filterable beyond limit, but overall adequate for a simple 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?
Single parameter 'limit' with 100% schema coverage including description and default. Description adds that results are ordered by rank, which complements the parameter semantics by implying limit constrains the top N results.
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?
Description clearly states verb 'Get', resource 'most popular board games', and ordering by popularity rank. Differentiates from sibling tools like 'get_game' (single game) and 'search_games' (filtered search).
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?
Implied usage for fetching popular games, but no explicit guidance on when not to use (e.g., if user wants filtered search) or alternatives. Sibling tool names suggest alternatives but description does not mention them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pipeworx_feedbackAInspect
Send feedback to the Pipeworx team. Use for bug reports, feature requests, missing data, or praise. Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim. Rate-limited to 5 messages per identifier per day. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | bug = something broke or returned wrong data. feature = a new tool or capability you wish existed. data_gap = data Pipeworx does not currently expose. praise = positive note. other = anything else. | |
| context | No | Optional structured context: which tool, pack, or vertical this relates to. | |
| message | Yes | Your feedback in plain text. Be specific (which tool, what error, what data was missing). 1-2 sentences typical, 2000 chars max. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses rate limit (5 messages per identifier per day) and content policy (no end-user prompt verbatim). For a feedback tool, these are key behavioral traits. No side effects or permissions needed.
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 concise sentences with no wasted words. Key information is front-loaded: purpose, use cases, content guidelines, and rate limit. Every sentence contributes meaningfully.
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's simplicity (feedback submission) and no output schema, the description is complete. It covers purpose, usage, parameter semantics, and constraints. No gaps remain.
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 parameters are well-documented. Description adds value by clarifying the message content expectations: 'Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim.' This goes beyond the schema's plain text description.
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?
Description explicitly states the tool's purpose: 'Send feedback to the Pipeworx team.' It lists specific use cases (bug reports, feature requests, missing data, praise) and distinguishes from sibling tools like ask_pipeworx or memory tools. The verb 'send' and resource 'feedback' are 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?
Description provides clear when-to-use guidance: 'Use for bug reports, feature requests, missing data, or praise.' It also gives explicit instructions on what to include/exclude in the message. Rate limit is mentioned, indicating usage constraints. No explicit alternatives needed as this is a distinct feedback channel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes behavior: retrieves by key or lists all. But does not disclose whether retrieval is case-sensitive, whether it returns full content or just metadata, or what happens if key does not exist (error vs empty result). Adequate but could be more transparent.
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, no redundancy. Front-loaded with purpose and alternative behavior. 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?
Given no output schema and no annotations, the description adequately explains behavior for a simple retrieval tool. Could mention what happens when key is missing, but overall complete enough for an agent to use correctly.
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 baseline is 3. Description adds value by explaining that omitting key lists all memories, which goes beyond the schema description. Effectively explains the optional nature of the parameter.
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?
Description clearly states the tool retrieves a stored memory by key or lists all memories when key is omitted. Uses specific verb 'retrieve' and resource 'memory', and distinguishes between two modes. No sibling tool does exactly this, so differentiation is 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 says when to omit key to list all memories. Implicitly suggests using it for retrieving context from earlier sessions. However, no guidance on when to use sibling tools like 'remember' (which stores) or 'forget' (which deletes), but context suggests these are complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_changesAInspect
What's new about an entity since a given point in time. type="company": fans out to SEC EDGAR (filings since), GDELT (news mentions in window), USPTO (patents granted since), in parallel. since accepts ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Returns structured changes + total_changes count + pipeworx:// URIs for each item. Use for "brief me on what happened with X" or change-monitoring workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today. | |
| since | Yes | Window start — ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Use "30d" or "1m" for typical monitoring. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. It discloses parallel fan-out, output structure (structured changes + total_changes + URIs), and since format alternatives. Read nature is implicit.
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?
Approximately 60 words, front-loaded with purpose, followed by technical details and usage guidance. No 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?
Explanation of return shape compensates for lack of output schema. Covers entity type, fan-out behavior, date formats, and usage intent. For a tool with 3 straightforward parameters and no output schema, this is fully sufficient.
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 baseline is 3. Description adds context: explains type is only 'company', gives examples for since, and clarifies value as ticker or CIK. This extra context justifies a 4.
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 states 'What's new about an entity since a given point in time' with specific details for type=company, and clearly differentiates from siblings like entity_profile and compare_entities.
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 says 'Use for brief me on what happened with X or change-monitoring workflows', which implies appropriate contexts. No explicit when-not, but sibling names provide enough distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses persistence behavior ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which is helpful. However, it does not mention any limitations (e.g., maximum key length, value size, or number of stored pairs), nor does it specify whether overwriting an existing key is allowed.
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 three sentences, each carrying meaningful information: purpose, usage guidance, and behavioral note. No fluff or repetition. Front-loaded with the core action.
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's simplicity (2 parameters, no output schema, no nested objects), the description is largely complete. It explains what the tool does, when to use it, and persistence details. A minor gap is the lack of explicit mention about overwriting behavior or limits, but overall it suffices.
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 baseline is 3. The description adds value by providing example keys (e.g., 'subject_property', 'target_ticker') and explaining that value can be any text. This contextualizes the parameters beyond the schema's generic 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 tool's purpose: 'Store a key-value pair in your session memory.' It specifies the resource ('session memory') and the action ('store'), and provides concrete use cases (saving intermediate findings, user preferences, context across tool calls).
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 usage context: 'Use this to save intermediate findings, user preferences, or context across tool calls.' It also notes persistence differences between authenticated and anonymous users. However, it does not explicitly exclude when not to use or mention alternatives like 'forget' or 'recall'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAInspect
Resolve an entity to canonical IDs across Pipeworx data sources in a single call. Supports type="company" (ticker/CIK/name → SEC EDGAR identity) and type="drug" (brand or generic name → RxCUI + ingredient + brand). Returns IDs and pipeworx:// resource URIs for stable citation. Replaces 2–3 lookup calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| value | Yes | For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses return values and the fact it consolidates calls, but lacks details on error handling, authentication, rate limits, or behavior on missing entities.
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 with no wasted words. Front-loaded purpose, followed by parameter details and benefit.
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?
Covers purpose, inputs, outputs, and benefit. Lacks error behavior and edge cases, but adequate for a simple tool with full schema coverage.
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?
100% schema coverage; the description adds examples and clarifies the 'value' parameter can be ticker, CIK, or name, providing context 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 resolves an entity to canonical IDs, specifies v1 supports type='company', and lists accepted inputs (ticker, CIK, name). It distinguishes from siblings by noting it replaces 2-3 lookup calls.
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 (single call vs multiple) and mentions the benefit, but doesn't explicitly state when not to use or list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_gamesAInspect
Search for board games by name. Returns title, year, player count, playtime, rating, price, and description. Use this to find games before fetching full details.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Board game name or partial name to search for, e.g. "Catan" or "Ticket to Ride" | |
| limit | No | Number of results to return (1–100, default 10) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of games matching the search |
| games | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the external API (Board Game Atlas) and return fields, but does not state whether the tool is read-only, requires authentication, or any side effects. For a search tool, this is adequate but minimal.
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 a single sentence that efficiently conveys the purpose and return fields. No wasted 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?
The description is sufficient for a simple search tool with two parameters. However, it lacks information about pagination, error handling, or any rate limits from the external API. With no output schema, the description could have provided more detail about the return format.
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 description does not need to add parameter details. It lists return fields, which adds some context, but does not clarify the 'limit' parameter beyond what the schema provides. 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?
The description clearly states the tool searches for board games by name using Board Game Atlas, and lists the return fields (name, year, player count, etc.). It distinguishes itself from sibling tools like 'get_game' (which likely returns a single game) and 'hot_games' (which returns trending games).
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 for searching games by name but does not explicitly state when to use this versus alternatives like 'get_game' for a single game or 'hot_games' for trending games. No exclusion criteria or when-not-to-use guidance is provided.
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!