The feedback board your AI agents work from: users vote, agents build over MCP. 22 tools.
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.
Average 3.4/5 across 22 of 22 tools scored. Lowest: 2.3/5.
All tools have clearly distinct purposes. The board, post, comment, vote, analytics, changelog, queue, and utility tools each target different resources or actions without overlap.
Most tools follow verb_noun snake_case (e.g., create_board, get_post). Two tools (ping, whoami) are not verb_noun but are standard conventions, keeping overall consistency high.
22 tools is well-scoped for a feedback board management server. Each tool covers a distinct operation without unnecessary duplication or bloat.
Covers core lifecycle for boards (CRUD + publish/unpublish), posts (CRUD + claim/release + status proposal + evidence), and comments (create/list). Missing comment update/delete and vote creation, but these are minor gaps for the domain.
add_evidenceAInspectAttach 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 | ||
| action_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that evidence is shown publicly and appears in the 'Implementation' section, but no annotations exist. It lacks details on permissions, side effects, or rate limits, though the core behavior is clear.
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 highly concise, using three short lines to convey the purpose, parameter hints, and user-facing impact with 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 provides context on public visibility and the output section, but given 6 parameters (4 required) and no explanation for most, it is incomplete. The existence of an output schema partially mitigates this, but parameter semantics are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 2 of 6 parameters (kind, ref) are explained in the description, despite 0% schema description coverage. The optional parameters (label, action_key) and required identifiers (slug, post_id) are left undocumented, forcing the agent to infer.
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 action (attach evidence) and target resource (post), with public visibility. It distinguishes from sibling tools like create_comment or create_post by specifying evidence attachment.
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 (to attach evidence to a post) and provides context about how evidence appears to voters. However, it does not explicitly exclude alternative tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_postBInspectAtomically 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description explains atomicity, default/max TTL, lease extension on re-claim, and 409 conflict response. It lacks details on success return values, permissions, and rate limits, but covers core locking behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The purpose is front-loaded, and the second sentence adds key behavioral details. No fluff or 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?
With 4 parameters and no schema descriptions, the description omits crucial parameter meanings (slug, post_id, agent_label) and does not describe the success response (though output schema exists). The tool's complexity is not fully addressed.
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 are absent (0% coverage). The description only explains 'ttl_seconds' (default, max). Parameters 'slug', 'post_id', and 'agent_label' are left unexplained, providing insufficient guidance for correct invocation.
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 ('claim a post') and resource ('post'), with a specific purpose ('double-work guard'). It is distinct from siblings like 'release_post', though not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it's used before working on a post to prevent double work, and explains conflict behavior. However, it does not provide explicit when-not-to-use guidance or mention alternatives like 'release_post'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_boardAInspectCreate 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: draft state, 404 until published, and publish_disabled error. Although no annotations exist, the description adequately covers the majority of behavioral aspects for a creation tool.
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 front-loaded with the primary purpose. It could be slightly more structured, but every sentence adds value without unnecessary verbosity.
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 low complexity, the description covers drafting behavior and key constraints. An output schema exists, so return values are documented. It lacks explicit permissions or usage prerequisites, but overall is adequate.
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 description adds meaning to the 'slug' and 'name' parameters beyond the schema (slug: URL path, unique, hyphenated; name: display name). The 'description' parameter is not explained, but schema shows default null and no further context is needed.
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 'Create a new feedback board, as a DRAFT' with a specific verb and resource. It distinguishes from sibling tools like publish_board and unpublish_board by indicating the board starts as a draft.
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 explains when to use (create draft board) and when not (expecting immediate live URL). It notes the need for publish_board and the 403 error if publish is disabled, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_commentCInspectComment 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It reveals that comments are posted as the board team but lacks details on permissions, side effects, or return behavior. The existence of an output schema is not mentioned.
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 front-loaded with the primary action. It uses one sentence effectively, though it could benefit from a bit more 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 the presence of 4 parameters, an output schema, and related sibling tools like list_comments, the description is incomplete. It omits parameter explanations, output details, and 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?
With 0% schema description coverage, the description should explain parameter meanings. It only mentions 'post' and 'comment' implicitly through the parent_comment_id, but does not clarify slug, body, or parent_comment_id 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 (comment on a post) and the optional replying behavior. It differentiates itself from sibling tools like list_comments, but could be more specific about the 'as the board team' identity aspect.
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 claim_post or add_evidence. There is no mention of prerequisites or context for using the comment feature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_postCInspectCreate a post on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| slug | Yes | ||
| tags | No | ||
| title | Yes | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose behavioral traits beyond being a write operation. It fails to mention side effects (e.g., slug uniqueness, overwrite behavior), permission requirements, or rate limits. The agent must guess at the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single sentence is concise, it is under-specified given the tool has 5 parameters and no schema descriptions. The description is too brief to be useful, sacrificing necessary detail for brevity.
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 lacks essential context for effective use. With 5 parameters (including optional body, tags, status) and no schema descriptions, the agent needs more guidance. The presence of an output schema is acknowledged but not leveraged in description.
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 description does not explain any parameters, leaving the agent to infer meaning from parameter names alone. Since the input schema has 0% description coverage, the description should compensate but does not. For example, 'slug' and 'status' could have ambiguous formats or constraints.
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 ('a post on a board'), which is specific and distinguishes it from sibling tools like create_comment or create_board. However, it lacks additional context about what constitutes a post or 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 is provided on when to use this tool versus alternatives such as update_post or propose_status. The description does not mention prerequisites, typical use cases, or conditions under which creation would fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_postCInspectDelete a post by hiding it through the developer API.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It reveals the post is 'hidden' (implying soft deletion), but does not disclose other behavioral traits such as reversibility, permission requirements, side effects on related resources (e.g., comments, votes), or idempotency.
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 but includes the redundant phrase 'through the developer API'. It could be more concise (e.g., 'Delete a post by hiding it'). Front-loads the core action but lacks 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 no annotations and minimal description, the tool definition is incomplete for a 2-parameter delete operation. It does not explain return values (despite having an output schema), error cases, or confirm success/failure behavior.
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 information about the parameters ('slug' and 'post_id'). The agent learns only their types from the schema, with no semantic context about their format, constraints, or relationships.
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 deletes a post by hiding it, which distinguishes it from creation or editing tools. However, it does not contrast with potential alternative deletion methods (e.g., permanent vs. soft delete), 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 on when to use this tool versus siblings like 'release_post' or 'update_post'. The description does not mention prerequisites, limitations, or contexts where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_analyticsCInspectGet read-only analytics for a board.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| period | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It indicates 'read-only', implying non-destructiveness, but provides no other traits such as required permissions, rate limits, or data boundaries.
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 concise sentence with no unnecessary words, but it may be too brief given the lack of supporting parameter details.
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?
While an output schema exists, the description fails to explain the 'period' parameter or what analytics data is returned, leaving significant gaps for the agent.
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 clarify the meaning of 'slug' or 'period', nor their expected formats or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves read-only analytics for a board, using a specific verb and resource. While it distinguishes from tools like 'get_board', it does not explicitly differentiate from potential analytics-related 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?
No guidance is provided on when to use this tool versus alternatives, nor are there any conditions or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_boardAInspectGet one board by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, permissions, or error handling. The description carries the full burden but reveals minimal 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 a single sentence that conveys the essential information without any 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?
For a simple retrieval tool with an output schema (not shown), the description adequately states what it does. It lacks mention of error conditions but is 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?
The single parameter 'slug' has zero schema coverage, but the description adds 'by slug' to clarify its role. While more detail (e.g., format) would be beneficial, the description compensates significantly.
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 says 'Get one board by slug,' which clearly states the verb (get), resource (board), scope (one), and lookup method (by slug). It effectively distinguishes from sibling tools like 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?
The description implies usage when you have a slug and need a single board, but does not provide explicit guidance on when not to use it or compare it to alternatives like list_boards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_changelogCInspectList shipped posts for a board.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'list shipped posts' but does not explain what 'shipped' means, whether it's read-only, pagination, ordering, or any side effects. Minimal behavioral 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?
The description is very concise (5 words) but lacks critical information. It is front-loaded with the action, but the brevity comes at the cost of completeness, making it less helpful.
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 required parameter and an output schema, the description should provide context about what constitutes a 'shipped post', the board association, and the nature of the output. It does not, leaving the user with 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?
Schema description coverage is 0%, and the description does not explain the 'slug' parameter at all (e.g., what it represents, how to obtain it, or its format). The description adds no value 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?
Description clearly states the action (list) and the resource (shipped posts for a board). It distinguishes from sibling tools like 'list_posts' by specifying 'shipped posts', indicating a specific subset, and from 'get_post' which retrieves a single 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 is provided on when to use this tool versus alternatives like 'list_posts', 'get_post', or 'get_board'. There is no mention of prerequisites or context (e.g., requiring a board slug).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postBInspectGet one post by board slug and post id.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states basic purpose without disclosing behavioral traits like permissions, error handling (e.g., missing post), or performance implications.
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?
One concise sentence with no fluff, directly communicates the tool's action and arguments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description is largely complete with output schema present. Could mention missing post handling or prerequisite board existence, but not critical.
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?
Description mentions parameters by name but adds little meaning beyond the schema. Does not explain format, constraints, or relation to each other. Schema coverage is 0%, so description should compensate more.
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 (get), resource (post), and identifiers (board slug and post id), distinguishing it from siblings like list_posts which returns multiple.
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 (e.g., list_posts for multiple posts, update_post for modification). Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_queueAInspectTop 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses sorting logic (owner-ranked then unranked by votes) and the intended workflow (call then claim). It does not mention authentication or rate limits, but for a read-only retrieval tool, the behavioral insight is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one framing sentence followed by two short explanatory sentences. Front-loaded with the core purpose, then details. 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 presence of an output schema, the description does not need to explain return values. It covers purpose, ordering, and usage context. The lack of parameter descriptions is a minor gap, but overall it's 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 coverage is 0% and the description does not explain the 'slug' (required) or 'limit' (optional) parameters. While the purpose is clear, the agent cannot infer what slug refers to 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?
Clearly states it retrieves top unclaimed posts in the owner's curated build order, with a specific verb ('get') and resource ('queue'). Distinguishes from siblings like list_posts and claim_post by focusing on unclaimed and curated order.
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 tells when to call: 'Call this to find the next thing to build, then claim_post before starting work.' Provides a clear usage pattern and implies when not to use (if you just want to list posts, use list_posts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_boardsAInspectList boards available to the caller's FeatureJet API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions boards are filtered by the caller's API key, which is a behavioral trait. However, it does not disclose pagination, ordering, or what the output contains (though output schema exists). No annotations are provided, so the description carries full burden but is 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 with no unnecessary words. It is front-loaded with the essential information: action and scope.
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 parameters and the presence of an output schema, the description is largely complete. It could mention that the list may be empty or that it includes all boards without pagination, but it is sufficient for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description does not need to add parameter details. It appropriately implies no filtering or options, which is clear.
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, specifying the scope ('available to the caller's FeatureJet API key'). It distinguishes from the sibling 'get_board' (singular) by implying a list vs. a single board, but does not explicitly differentiate from other board-related 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?
No explicit guidelines on when to use this tool versus alternatives like 'get_board' or 'publish_board'. The usage is implied: to retrieve all boards accessible by the API key. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_commentsCInspectList comments for a post.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a minimal description, the tool's behavior (e.g., pagination, ordering, authorization requirements) is not disclosed. The output schema exists but is not described here, leaving the agent uncertain about the response format.
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 words, which is too short to provide meaningful context. It lacks structure and is under-specified, not concise in a helpful way.
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 parameters and no annotations, the description is incomplete. It does not explain return values, common use cases, or how this tool fits with sibling tools. The output schema may help but is not referenced.
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 what 'slug' or 'post_id' refer to. The agent must infer their meanings from parameter names alone, which 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?
The description uses the verb 'List' and resource 'comments for a post', clearly indicating the action and target. However, it does not differentiate from sibling tools like 'create_comment' or 'get_post', which could cause 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. There is no mention of prerequisites (e.g., post existence) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_postsBInspectList 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully explain behavior. It mentions listing and filtering but omits details on pagination (limit/offset), authentication, rate limits, or response structure. The output schema exists but is not summarized.
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?
One sentence, directly to the point, no redundant or superfluous information. Every word contributes to understanding the tool's 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?
Adequate for a list tool with output schema, but lacks explanation of pagination, sorting, or error handling. Considering the sibling set and parameter count, the description is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It notes filters (status, search, tag) mapping to some parameters, but leaves slug, limit, offset unexplained. The description adds only partial clarity for 6 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 verb 'list', resource 'posts', and context 'for a board' with optional filters (status, search, tag). It distinguishes from sibling tools like get_post (single post) and list_boards (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing posts under a board, but provides no explicit guidance on when to use this tool over alternatives (e.g., get_post, get_queue). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_votesBInspectList vote metadata for a post.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure: only states 'List vote metadata'. No details on pagination, sorting, or what 'metadata' entails. Without annotations, the description does not sufficiently inform 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 with no extraneous words. Front-loaded with verb and resource.
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?
Adequate for a simple list tool with an output schema, but lacks parameter descriptions and usage context. Not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description offers no explanation for 'slug' or 'post_id'. Adds no value beyond the 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?
Clearly states the action (list) and resource (vote metadata) with context (for a post), distinguishing it from sibling tools like list_comments or list_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?
Implies usage as a read operation for vote metadata, but no explicit when-to-use, prerequisites, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAInspectCheck MCP and FeatureJet API reachability for the caller's key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly identifies the action (checking reachability) but does not disclose additional behavior such as side effects, rate limits, or authentication requirements. However, for a simple ping, 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 a single, concise sentence that is front-loaded with the key action. Every word contributes meaning 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?
Given the tool's simplicity (no parameters, no annotations), the description is fully adequate. The presence of an output schema further reduces the need for explaining return values. The description provides sufficient context for an agent to select and invoke the tool 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?
The tool has no parameters, so the description naturally adds value by explaining what the tool does. The schema coverage is 100% since there are no parameters, and the description provides 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's purpose: checking reachability of MCP and FeatureJet API for the caller's key. It uses a specific verb and resource, distinguishing it from sibling tools that perform CRUD operations.
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 health checks but does not explicitly state when to use versus alternatives or provide guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_statusAInspectPropose 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 | ||
| action_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: no public board changes, no voter notification until human confirms, new proposals replace pending ones. Lists valid status values. With no annotations, the description fully informs the agent of safety and implications.
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?
Description is well-structured: main purpose first, then behavioral details, then contrast. A bit verbose but each sentence adds value. Could be slightly shortened without losing meaning.
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 presence of an output schema, return values are not required. Covers the proposal mechanism, contrast with sibling, and status options. Could mention how to confirm or manage proposals, but adequate for a single-purpose 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 0%, so description must compensate. It explains the 'status' parameter and its allowed values, but does not describe slug, post_id, note, or action_key. Partial compensation—core parameter is covered, but others lack 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?
Clearly states the tool's purpose: 'Propose a status change for the board owner to confirm.' It explains the agent-honest behavior and distinguishes from update_post by emphasizing human confirmation. The description directly answers what the tool does.
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 preferring this tool over update_post for direct status flips: 'Prefer this over update_post's direct status flip.' It provides clear context for when to use (gentle, human-confirmed updates) and implies when not to use (direct changes without approval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_boardAInspectPublish 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It discloses that publishing is off by default, requires specific scopes and subscription, and returns 403 errors in certain cases. This provides good insight into the tool's behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs: the first states the purpose, and the second adds important usage constraints. It is front-loaded and every sentence adds value, though the error details could be formatted more succinctly.
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 (publishing to public internet, auth, subscription), the description covers key constraints and error scenarios. The output schema exists, so return values need not be explained. However, the lack of parameter explanation is a gap for 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?
The input schema has one required parameter 'slug' with 0% description coverage. The description does not explain what the slug is, how to obtain it, or any format requirements. This adds minimal meaning beyond the schema definition.
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 core action: 'Publish a board so it is live at its public URL.' It distinguishes from siblings like 'unpublish_board' by explicitly describing the publishing action and its prerequisites.
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 explicit conditions for use: off by default, requires opt-in, write/admin scoped key, and active subscription. It lists error cases (403) when these are not met, giving clear guidance on when the tool should and should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
release_postCInspectRelease a post's claim so other agents can pick it up.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral context. It only states the action and outcome, but misses details on side effects, permissions, or idempotency.
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?
One sentence, no waste, but lacks structure. Acceptable for the limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description is incomplete: no parameter details, no usage context, and minimal behavioral info.
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 description adds no meaning to the parameters 'slug' and 'post_id'. With 0% schema coverage, this is a critical gap.
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 'release', the resource 'a post's claim', and the outcome 'so other agents can pick it up', distinguishing it 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?
No explicit guidance on when to use or not use the tool, nor references to alternatives. The description implies usage after a claim, but lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublish_boardAInspectReturn 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States explicitly that nothing is deleted and the action is reversible ('publish it again to bring it back'). No annotations, so description carries load adequately.
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 minimal waste. Front-loaded with purpose, then clarifying non-destructive behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle action with one parameter and no output schema needed, description covers purpose, effect, and reversibility. Could mention board metadata retention, but not critical.
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 'slug' has no description in schema or description. Agent must infer what a 'slug' is (likely board identifier). No added value 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?
Clear verb ('return a board to draft'), resource ('board'), and effect ('public URL stops serving it'). Distinct from sibling publish_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?
Implied usage: when you want to make a board private. No explicit when-not or alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_postCInspectUpdate mutable post fields; null queue_rank explicitly un-ranks.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| slug | Yes | ||
| tags | No | ||
| title | No | ||
| pinned | No | ||
| status | No | ||
| post_id | Yes | ||
| queue_rank | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description must carry the full burden of behavioral disclosure. It only mentions 'update mutable' (implying write) and the null behavior of queue_rank. It does not disclose side effects, permission requirements, or the scope of mutable fields.
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 short and front-loaded with the main action. It achieves efficiency with two clauses. However, it could be expanded without losing conciseness to cover more parameters or behaviors.
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 8 parameters, 2 required, no annotations, and an output schema not referenced, the description is insufficient. It does not explain return values, validation rules, or the full set of mutable fields, leaving the agent to infer much from the schema alone.
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 only adds meaning for one parameter (queue_rank: null explicitly un-ranks). The other seven parameters (body, slug, tags, title, pinned, status, post_id) receive no semantic clarification 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 states 'Update mutable post fields', which clearly identifies the action and resource. It also adds a specific nuance about queue_rank null behavior. However, it does not explicitly distinguish from sibling tools like create_post or delete_post, though the distinct action is evident.
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 versus alternatives (e.g., create_post for new posts, get_post for reading). No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspectConfirm the caller's API key by listing accessible boards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'listing accessible boards' as a side effect, but fails to specify read-only nature, authentication requirements, or any potential side effects. The description only partially covers behavioral traits.
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, focused sentence with no unnecessary words. It is front-loaded with the core 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 a simple tool with no parameters and an output schema, the description is adequate but incomplete. It does not explain what the output contains (e.g., board names, IDs) beyond 'accessible boards'. With an output schema, further explanation is not required, but adding context about the return value 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?
The input schema has zero parameters, so the description adds no parameter information. Following the baseline rule for 0 parameters, a score of 4 is appropriate. The description does not contradict 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 tool name 'whoami' is self-descriptive, and the description clearly states the action ('Confirm the caller's API key') and the method ('by listing accessible boards'). It effectively distinguishes from siblings like 'ping' or '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?
The description implies use for identity verification but does not explicitly state when to use this tool versus alternatives (e.g., 'ping' for connectivity). No exclusions or context are 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.
No comments yet. Be the first to start the discussion!