FeatureJet
Server Details
The feedback board your AI agents work from: users vote, agents build over MCP. 22 tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 3.3/5 across 21 of 22 tools scored. Lowest: 2.3/5.
Each tool targets a distinct resource and action: boards, posts, comments, votes, claims, evidence, analytics, changelog, publishing, and utilities. There is no functional overlap; even similar actions like propose_status vs update_post serve different purposes (human-confirmed vs direct update).
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_board, get_post, publish_board). The naming is predictable and uniform across the entire set.
22 tools is on the higher side of the typical range, but each tool serves a clear purpose within the feedback board domain. The count is justified by the variety of resources (boards, posts, comments, votes) and workflows (claims, proposals, publishing, analytics).
The tool set covers CRUD and lifecycle operations for boards and posts, plus specialized actions (claims, evidence, status proposals, analytics). Minor gaps exist: comment update/delete and board settings modification are missing, but agents can accomplish core tasks without dead ends.
Available Tools
22 toolsadd_evidenceBInspect
Attach implementation evidence to a post (shown publicly).
kind is one of branch|commit|pr|transcript|url; ref is the branch
name, commit sha, or URL. Voters see these in the post page's
"Implementation" section.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | ||
| kind | Yes | ||
| slug | Yes | ||
| label | No | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry behavioral transparency. It mentions the evidence is shown publicly but doesn't disclose side effects, required permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short overall, but the second line is formatted as a continuation with indentation, which may not parse cleanly. Could be more concise and structured.
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?
Description is minimal, lacking details on output, prerequisites, and error handling. Even with an output schema, the description should cover more context for a 5-parameter 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 description coverage is 0%. Description explains kind and ref partially, but slug, label, and post_id are not described. With 5 parameters, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Attach' and resource 'implementation evidence to a post'. Distinguishes from sibling tools like claim_post or create_post as it specifically attaches evidence.
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?
Gives some context about kind values and ref meaning, but no explicit when-to-use or when-not-to-use compared to alternatives. Usage is implied but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_postAInspect
Atomically claim a post before working on it (double-work guard).
ttl_seconds defaults to 3600 (max 86400); re-claiming with the same
key extends the lease. Returns 409 if another key holds a live claim.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes | ||
| agent_label | No | ||
| ttl_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: atomic operation, TTL defaults and max, re-claiming extends lease, and 409 conflict response. This is comprehensive for a locking tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (three sentences) and front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, conflict handling, and TTL behavior. However, it omits details about the output schema and the 'agent_label' parameter. Given the presence of an output schema, the omission of return values is acceptable, but the missing parameter explanation is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The description only explains 'ttl_seconds' (default and max). It does not describe 'slug', 'post_id', or 'agent_label', which are important for usage. The agent_label parameter, in particular, is not explained.
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 'claim' and the resource 'post', with the purpose of preventing double-work when working on a post. This distinguishes it from sibling tools like 'release_post'.
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 the tool (before working on a post) and provides details about TTL and conflict behavior. However, it does not explicitly contrast with alternatives or specify when not to use it, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_boardAInspect
Create a new feedback board, as a DRAFT.
`slug` is the board's URL path segment (lowercase, hyphenated, unique);
`name` is the display name. The new board's public URL 404s until a
human publishes it from the dashboard -- `publish_board` is off by
default (403 `publish_disabled`).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| slug | Yes | ||
| description | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: creates a draft, slug as URL path, public 404s until published, publish_board disabled by default (403). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear opening statement followed by necessary details. No unnecessary words, though could be slightly shorter.
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 output schema exists, the description adequately covers creation behavior, prerequisites, and post-creation state. It mentions 404 and 403 errors, providing completeness for this type of 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 has 0% coverage, but description adds meaning for slug (lowercase, hyphenated, unique) and name (display name). It does not elaborate on description parameter, which remains partially undocumented.
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 creates a new feedback board as a DRAFT, with specific verb and resource. It distinguishes from siblings like publish_board by explaining the draft status and 404 behavior.
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 (to create a draft board) and notes that publish_board is off by default, but does not explicitly compare with other create tools. It provides clear context on slug uniqueness and required publishing step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_commentBInspect
Comment on a post as the board team, optionally replying to a comment.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| slug | Yes | ||
| post_id | Yes | ||
| parent_comment_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | 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 cover behavioral traits. It mentions acting as the board team, which is useful, but fails to disclose whether the action is irreversible, requires authentication, or has side effects. This is a significant gap.
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 conveys the core purpose without excess verbiage. It is front-loaded, but could be slightly more structured to include parameter hints.
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?
Despite having an output schema, the description lacks essential context for a creation tool, such as authentication requirements, error handling, or parameter details. The agent is left with significant gaps.
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?
With 0% schema description coverage, the description must compensate. It only hints at 'post' and 'optionally replying,' leaving the parameters (slug, post_id, body, parent_comment_id) unexplained. Agents cannot infer proper usage without additional context.
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 explicitly states 'Comment on a post as the board team, optionally replying to a comment,' which clearly identifies the action (comment), resource (post), and context (board team). It distinguishes itself from sibling tools like list_comments by focusing on creation.
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 ('as the board team') but does not explicitly state when to use this tool versus alternatives, nor does it provide any when-not-to-use guidance. No comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_postCInspect
Create a post on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| slug | Yes | ||
| tags | No | ||
| title | Yes | ||
| status | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'Create a post', implying a mutation, but omits details on permissions, side effects, or return value (though output schema exists). Insufficient for understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which makes it concise but at the cost of completeness. It is front-loaded but lacks essential details, resulting in an adequate but minimal structure.
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 5 parameters (2 required) and no enums or nested objects, the description is incomplete. It fails to explain the meaning of the 'slug' parameter or the purpose of optional fields like 'status'. The output schema exists but doesn't compensate for the lack of parameter context.
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 0%, and the description adds no meaning beyond the schema. It does not explain that 'slug' likely refers to the board, nor does it describe 'body', 'tags', or 'status' parameters.
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 action (create) and resource (post on a board), distinguishing it from siblings like update_post or delete_post. However, it does not clarify the role of the 'slug' parameter in identifying the board, leaving some ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives such as claim_post, release_post, or propose_status. The description lacks context for selecting the appropriate tool among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_postCInspect
Delete a post by hiding it through the developer API.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'hiding it' without explaining effects (reversible? permanent?), required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, but lacks essential details. Conciseness compromises completeness.
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 two required params and no annotations, the description should explain usage context and parameter meaning. It fails to do so, leaving agent underinformed.
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 0% description coverage for parameters (slug, post_id). Description adds no meaning, examples, or explanations for these parameters.
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 action (delete) and resource (post), and distinguishes from siblings like unpublish_board or update_post by specifying 'hiding through the developer API'.
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?
No guidance on when to use this tool versus alternatives (e.g., unpublish_board, update_post status). Agent has no context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_analyticsCInspect
Get read-only analytics for a board.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| period | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only notes 'read-only', but with no annotations, it fails to disclose permissions, rate limits, or side effects. More behavioral context is needed for safe invocation.
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, front-loaded sentence with no wasted words. However, it may be too brief for adequate context.
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?
Despite having an output schema, the description omits essential context for parameters and usage, leaving gaps in understanding what analytics are returned and how to use the tool properly.
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 0%, and the description does not explain parameters 'slug' or 'period'. The agent gains no additional meaning beyond bare property names.
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 and resource ('Get read-only analytics for a board'), distinguishing it from siblings like 'get_board'. However, it lacks explicit differentiation from similar tools.
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 provides no guidance on when to use this tool vs alternatives. Siblings like 'get_board' or 'get_changelog' are not mentioned, leaving context-dependent selection unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_boardBInspect
Get one board by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 of behavioral disclosure. The description only states it retrieves one board, but does not disclose behavior such as error handling when slug is invalid, whether it returns the full board object, or any side effects. Minimal behavioral context beyond the basic action.
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?
Exceptionally concise with one phrase that includes verb, resource, and key parameter. No unnecessary words, front-loaded with essential 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?
Although an output schema exists (not shown), the description is too minimal. It lacks context about expected behavior, error states, or relationship to other tools. For a simple tool, this might suffice, but given no annotations and minimal description, it leaves gaps for an AI agent to infer 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?
Input schema has 0% description coverage, and the description only mentions 'by slug' without adding meaning. No explanation of what a slug is, its format, or examples. The description does not compensate for the schema's lack of parameter documentation.
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 action (Get) and resource (board) with the specific parameter (by slug). It differentiates from sibling tools like list_boards (which retrieves multiple boards) and create_board (which creates a board).
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?
No guidance on when to use this tool versus alternatives like list_boards or get_post. No prerequisites, scenarios, or exclusions provided. The description only indicates a prerequisite (having a slug) but does not help an agent decide between this and other board-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_changelogCInspect
List shipped posts for a board.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'List' implying read-only, but does not confirm safety, auth requirements, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action. Very concise, though at the cost of detail.
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?
Despite having output schema, the description lacks context about the concept of 'shipped posts', board identification, and differentiation from numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'for a board' implying slug identifies a board, but no details on format or how to find it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists shipped posts for a board, distinguishing it from siblings like list_posts (all posts) and get_post (single post). However, it does not explicitly mention 'changelog' or further nuance.
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?
No guidance is provided on when to use this tool versus alternatives like list_posts or get_post. It lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postBInspect
Get one post by board slug and post id.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description provides no behavioral details (e.g., error responses, permissions, read-only guarantee). The description only states the basic action.
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 with no extraneous information. All words are meaningful and front-load the 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?
Tool is simple with 2 required params and output schema exists. Description covers the core function. Minor omission: doesn't mention what happens if post not found, but for a get operation this is often acceptable.
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 0%, but description adds context by naming the parameters' roles ('by board slug and post id'). However, no additional format or constraints are explained beyond the schema's property names.
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 'post', and identifiers 'board slug and post id'. It effectively distinguishes from siblings like list_posts (get multiple) and create_post.
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?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that list_posts might be needed to find post IDs, or that this tool is for single post retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_queueBInspect
Top UNCLAIMED posts in the owner's curated build order.
Owner-ranked posts (queue_rank, lower = sooner) come first, then
unranked planned posts by votes. Call this to find the next thing to
build, then claim_post before starting work.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions ordering and recommendation to use claim_post. Does not disclose read-only nature, permissions, rate limits, or any side effects beyond the implied mutation of claim_post step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key info, 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 purpose and ordering, but lacks parameter explanations and any notes on output format (though output schema exists). Adequate but not comprehensive.
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 two parameters (slug, limit) with 0% description coverage. Description does not explain what slug represents (likely board identifier) or what limit controls (number of 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?
Clearly states it returns top UNCLAIMED posts, explains ordering logic (queue_rank then votes), and distinguishes from sibling tool claim_post.
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 advises to call this to find next build item and then use claim_post. Provides clear context but lacks explicit when-not-to-use or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_boardsAInspect
List boards available to the caller's FeatureJet API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 only states the tool lists boards but does not mention any behavioral traits such as response structure, pagination, caching, or rate limits. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that directly conveys the tool's purpose with no extraneous information. 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 the tool's simplicity (zero parameters, output schema exists to describe return values), the description is complete. It clearly states what the tool does, and the output schema covers the return values. No additional context is needed.
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 tool has zero parameters, and the schema coverage is 100%. The description adds clear meaning about the tool's purpose beyond the empty schema, effectively communicating what the tool does. This exceeds the baseline expectation for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists boards available to the caller's API key, using a specific verb and resource. It distinguishes from sibling tools like list_comments, list_posts, etc., which have different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the tool's purpose is straightforward, with many sibling tools, some context on when to choose this over other list tools would be helpful. Score reflects lack of explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_commentsCInspect
List comments for a post.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only implies a read operation but does not mention pagination, authentication, rate limits, or any side effects. The presence of an output schema helps but behavioral context is missing.
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?
While very concise (one sentence), the description is too minimal to be effective. It lacks structure and provides no additional context beyond the tool name. A better description would front-load the purpose and add parameter explanations.
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 2 required parameters, no descriptions in schema, and an output schema is present but unseen, the description is severely incomplete. It fails to explain parameters, return value structure, or usage context.
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 0% and the description does not explain the purpose of 'slug' or 'post_id'. The description only says 'for a post', which implies post_id identifies the post, but 'slug' is left undefined. No value added beyond schema names.
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 'List comments for a post' clearly indicates the action (list) and resource (comments) with context. However, it does not differentiate from sibling tools like create_comment, which is a different action.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or comparison with other list tools like list_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_postsBInspect
List posts for a board, optionally filtered by status, search, or tag.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| tag | No | ||
| slug | Yes | ||
| limit | No | ||
| offset | No | ||
| status | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It mentions listing with optional filters but omits pagination behavior (limit/offset), ordering, or response format beyond what output schema provides. Missing critical behavioral details.
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 concise sentence front-loads purpose and key filters. No wasted words, but could be slightly more structured to list filters explicitly.
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 6 parameters and no annotations, description covers main purpose and filters but lacks pagination context and search query format. Output schema exists, but description could be more complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It maps 'status, search, or tag' to parameters status, q, and tag, but does not explain limit, offset, or the format of search query. Adds minimal meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List', resource 'posts', scope 'for a board', and optional filters (status, search, tag). Effectively distinguishes from siblings like get_post (single post) and list_boards.
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?
Implies usage for listing posts with filters, but lacks explicit guidance on when to use versus alternatives like get_post for a single post. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_votesCInspect
List vote metadata for a post.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It only states the function but does not reveal whether the operation is read-only, requires authentication, or any side effects. The read-only nature is implied but not explicit.
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 and is concise, but it lacks essential structure such as parameter context or usage hints. It is not overly verbose, but the brevity sacrifices completeness.
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?
Although an output schema exists, the description is insufficient for a tool with no annotations and zero parameter documentation. It fails to cover basic behavioral aspects and parameter roles, leaving the agent underinformed.
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 0%, yet the description adds no meaning to the parameters. It does not explain what 'slug' or 'post_id' represent beyond their names, nor how they relate to the post context.
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 a specific verb and resource ('List vote metadata for a post'), clearly indicating the action and scope. It distinguishes from sibling tools like list_comments and list_posts, but does not explicitly contrast with them.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAInspect
Check MCP and FeatureJet API reachability for the caller's key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses the basic action (checking reachability) and the context (two APIs, caller's key). However, it does not detail expected outcomes on success/failure or response structure, relying on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. Every word adds value, making it 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?
For a tool with zero parameters and a simple health-check action, the description is complete. The existence of an output schema (not shown) covers return values, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds no parameter information as none exist, meeting the baseline expectation for parameter-free tools.
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 a specific verb ('Check') and clearly identifies the target resources ('MCP and FeatureJet API') and scope ('for the caller's key'). It distinctly separates from sibling tools, none of which perform health checks.
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 implicitly suggests use for reachability verification but does not explicitly state when to use vs alternatives or provide usage exclusions. Given no similar sibling, the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_statusAInspect
Propose a status change for the board owner to confirm.
The agent-honest way to mark work done: nothing changes on the
public board and no voter is notified until a human confirms the
proposal from the dashboard. status is one of
open|planned|in_progress|shipped|declined; a new proposal replaces
any pending one. Prefer this over update_post's direct status flip.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| slug | Yes | ||
| status | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that no public change occurs, no voter notification, and new proposal replaces pending one. Could mention side effects more but covers key behaviors.
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?
Succinct with three sentences: clear purpose, behavioral details, and sibling comparison. 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 purpose, behavior, and usage hints. Output schema exists so return explanation isn't needed. Missing parameter details but acceptable.
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?
Lists allowed status values (open|planned|in_progress|shipped|declined) but does not explain note, slug, or post_id. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States verb (propose) and resource (status change) clearly, and explicitly distinguishes from sibling tool update_post.
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 guidance to prefer this over update_post, explains proposal behavior (no public change, human confirmation). Lacks explicit when-not-to-use but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_boardAInspect
Publish a board so it is live at its public URL.
OFF BY DEFAULT. Putting a board on the public internet is a human
decision: unless the FeatureJet deployment has opted in, this returns
403 `publish_disabled` and the owner publishes from the dashboard.
Where it is enabled it needs a `write` (or `admin`) scoped key and an
active subscription -- an org without one gets 403
`subscription_required`.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral details: off-by-default, requires opt-in, needs write/admin scoped key, active subscription, and specific 403 error codes. This goes well beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then explains constraints in a structured way. While slightly verbose, every sentence adds useful information without repetition.
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 complexity (auth, subscriptions, opt-in), the description covers essential behavioral and error details. An output schema exists, so return values need not be explained. Missing guidance on obtaining slug, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should explain the only parameter 'slug'. It does not define what slug means, though it is inferrable from the tool name. Minimal value added 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?
The description explicitly states 'Publish a board so it is live at its public URL,' which is a clear verb+resource combination. It distinguishes well from siblings like 'unpublish_board' which reverses this action.
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 when a board should be made public, but does not explicitly state when not to use or mention alternatives. It provides conditions for errors but lacks explicit guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
release_postBInspect
Release a post's claim so other agents can pick it up.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral traits like reversibility, ownership requirements, or effects on other agents. Minimal disclosure.
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, directly to the point, no redundant 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?
Minimal but not entirely insufficient given output schema exists. However, more context on release semantics and agent interaction would improve completeness.
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 0% and description does not elaborate on parameters. Only infers 'slug' and 'post_id' identify the post, no additional meaning.
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 uses specific verb 'release' and resource 'post's claim', clearly stating the purpose. Distinguished from sibling 'claim_post'.
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?
Implies usage after claiming a post, but no explicit when-to-use or when-not-to-use. No mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublish_boardAInspect
Return a board to draft so its public URL stops serving it.
Nothing is deleted; publish it again to bring it back.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description effectively discloses key behaviors: it changes the board to draft state, stops the public URL, does not delete anything, and is reversible via republishing. It lacks details on authentication or rate limits, but for a simple tool this is adequate.
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 extremely concise: two short sentences that front-load the main action and provide key context in a clear, efficient manner. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the state change, effects, safety, and reversibility. The output schema exists, so return values are not needed. Missing parameter explanation is a gap, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'slug' with no description. The tool description does not explain this parameter, leaving the agent to infer its meaning. With 0% schema description coverage, the description should compensate but fails to add any parameter semantics.
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 action: 'Return a board to draft so its public URL stops serving it.' It distinguishes from the sibling publish_board by mentioning reversibility, and the purpose is unambiguous.
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?
While not explicitly stating when to use vs alternatives, the description clearly implies usage: when you want to take a board offline. It mentions that it can be republished, providing context. No exclusion criteria are given, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_postCInspect
Update mutable post fields.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| slug | Yes | ||
| tags | No | ||
| title | No | ||
| pinned | No | ||
| status | No | ||
| post_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description bears full burden. It fails to disclose partial vs full update, idempotency, permission needs, or side effects like status changes.
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?
Extremely brief (4 words) but not usefully concise. Critical information is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no schema descriptions, and no annotations, the description is grossly incomplete. An agent cannot determine correct usage beyond the tool's basic purpose.
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 0%. The description adds no information about any of the 7 parameters, leaving the agent to infer meaning from names alone.
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?
'Update mutable post fields' clearly indicates a write operation on a post resource. It distinguishes from create_post or delete_post, but 'mutable fields' is vague without specifying which fields.
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?
No guidance on when to use this tool vs alternatives like create_post or delete_post. Lacks context about prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Confirm the caller's API key by listing accessible boards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions listing boards but does not disclose read-only nature, error behavior on invalid keys, or output format. 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?
Single sentence, no unnecessary words, front-loaded with purpose. Highly 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 zero parameters and a simple purpose, the description is mostly complete. The output schema exists, so lack of return value description is acceptable. However, it could briefly note that the tool tests authentication.
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?
No parameters exist, and schema coverage is 100%. Description correctly adds no param info; baseline score 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 'Confirm' and the resource 'API key', and specifies the method 'listing accessible boards'. It distinguishes this tool from siblings which are CRUD operations on boards and posts.
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 verifying API key validity. It does not explicitly state when not to use, but given the tool's simplicity and lack of siblings with similar purpose, this is sufficient.
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!