backloggd-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Tool purposes are mostly distinct and clearly described. Some pairs like get_game_lists vs get_lists or check_games vs query_library have overlapping concepts, but their descriptions and parameters make them distinguishable. The high number of tools introduces some potential confusion, but each has a unique role.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern (e.g., add_favorite_game, get_user_profile, delete_list). Even the outlier backloggd_whoami fits the overall style of a self-descriptive command. There is no mixing of conventions or chaotic naming.
Tool Count2/5
At 45 tools, this is well beyond the 'heavy' threshold of 25. While the Backloggd domain is broad, many tools could be consolidated (e.g., combining shelf/rating/review setters into a single log editor, merging query/check/find variants). The large surface area is likely to overwhelm agents.
Completeness5/5
The tool set covers nearly all core Backloggd workflows: game discovery, library management, ratings, reviews, play sessions, lists, social interactions, and account utilities. Confirmation flows for destructive actions are also present. There are no obvious dead ends; every tool needed for typical use cases exists.
Average 4.2/5 across 45 of 45 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, satisfying safety concerns. The description adds the behavioral scope (user-created lists) and the response feature (game counts), providing some context beyond annotations. However, it doesn't disclose pagination behavior, sorting, or authentication defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, easily readable at a glance. It is slightly under-specified but appropriately short for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return structure more fully. It only mentions game counts, leaving out pagination, sorting options, and the default-to-authenticated-user behavior. These gaps make the description incomplete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 67%, the description adds no meaningful parameter semantics. It doesn't clarify the sort enum or page usage, and the only parameter implication ('a user' referencing username) is already stated in the schema. It fails to compensate for the undocumented sort parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource being retrieved (a user's created lists) and mentions a key detail (game counts), effectively conveying the tool's purpose. It doesn't explicitly differentiate from sibling tools like get_list or get_game_lists, but the scope ('created by a user') provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of any alternative tools. Usage must be inferred from the title and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and the description adds 'paginated' as a behavioral trait. However, it does not disclose auth requirements, rate limits, error behavior, or what happens if a list doesn't exist. With annotations covering safety, the added context is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) and front-loaded with the core purpose. It avoids unnecessary words, though it could perhaps be a complete sentence rather than a fragment. Overall, it's appropriately sized for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description covers the basic purpose but lacks context on how the list_slug is obtained or when to prefer this over related tools. It is usable but not fully complete for an AI agent navigating many sibling tools without additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (page, username, list_slug), so the schema already explains each parameter. The description's mention of 'paginated' aligns with the 'page' parameter but adds no new semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get one list's games' and description 'The games in a single list, paginated' clearly indicate the tool returns the games contained in a specific list. It distinguishes from sibling tools like 'get_lists' by explicitly stating 'single list' and 'games', though it doesn't name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as 'get_lists' or 'get_game_lists'. It only implies that one needs a list_slug, but does not explain scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal context by specifying 'recent' and 'on your account,' but it does not disclose behavioral traits like result limits, read-state effects, or pagination, so it adds only modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words. It is appropriately sized for a simple read-only tool and delivers the core message efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should compensate by explaining what the response contains (e.g., list of notifications, fields like message and timestamp). 'Recent notifications on your account' is too vague to convey the data shape or any behavioral details, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema contains no properties. With no parameters to document, the description need not explain syntax or meaning; the baseline of 4 for 0-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recent notifications on your account' clearly identifies the resource (notifications) and scope (user's account), making the tool's purpose understandable. While the verb is implied rather than explicit, the name 'get_notifications' reinforces the retrieval action, and there are no sibling tools for it to be confused with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what conditions warrant it, or how it differs from alternatives. It merely states what it returns, leaving the agent without contextual cues for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is read-only and non-destructive, so the description's lack of safety warnings is acceptable. It adds minimal behavioral context (e.g., community scope, included review fields) but omits pagination behavior or any ordering/filtering details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the resource and its key attributes with zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, paginated tool with full schema coverage and supportive annotations, the description adequately conveys what is returned. It could mention pagination specifics or sorting, but it is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add any extra semantic meaning beyond the schema for the game or page parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: community reviews for a game, and specifies key included fields (ratings, authors, like counts). It distinguishes from sibling get_user_reviews by focusing on game-specific reviews, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like get_user_reviews. The description does not state when to prefer this tool or what it cannot do, leaving the agent to infer usage from the name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context by specifying the like is on 'someone's review' and implies the current user's action. However, the word 'toggle' is slightly inconsistent with the idempotentHint and the boolean parameter, though not a direct contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately concise for a simple action, though it omits parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is under-specified. It does not clarify what the boolean 'liked' controls, and there is no output schema to compensate. The annotations provide some safety context, but the core parameter semantics are unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'liked' boolean parameter. It implies review_id via 'review' but does not clarify that 'liked' sets the desired state (true=like, false=unlike). This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle your like on someone's review' clearly identifies the action (toggle like) and the resource (a review), distinguishing it from sibling tools like set_game_like that target games. The title reinforces the action with 'Like or unlike a review.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The resource is clear from the name, so usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the 'heart' metaphor and implies a state toggle, but does not disclose additional behavior like authentication needs, effects on like counts, or error cases. It is sufficient but not richer than the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with robust annotations, the description covers the core purpose. However, it does not explain post-invocation behavior (e.g., return value, errors, or effects on the game's like count), and there is no output schema to compensate. Some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives a thorough description for 'game' but none for 'liked'. The description's 'toggle the heart' implies that 'liked' controls the heart state, but it does not explicitly state that true means like and false means unlike. This adds some meaning but leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle the heart') and the target resource ('a game'), which immediately distinguishes it from sibling tools like like_review (which targets reviews) and add_favorite_game (which manages favorites). The wording is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or the relationship to sibling tools such as like_review or add_favorite_game.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is established. The description adds context that the feed comprises friends' actions, your own actions, and actions on your content, which is useful. It does not disclose response format or pagination behavior, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence beginning with 'Recent activity', followed by a concise enumeration of scopes. Every clause adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three optional parameters and no output schema, the description covers the essential semantics of what the activity feed contains. It does not elaborate on the response structure or pagination details, but the schema's page parameter is self-explanatory and the overall context is sufficient for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'scope' parameter, which lacks a schema description, by detailing what each enum value represents. The 'page' and 'username' parameters are already described in the schema, so the description's focus on scope fills a real gap and enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning recent activity, with explicit breakdown of the three scopes ('friends', 'you', 'inbound'). It aligns with the title and gives a concrete sense of what the tool does. It does not explicitly distinguish it from sibling tools like get_notifications or get_journal, but the scope semantics provide enough clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what each scope returns, but it does not say when to use this tool instead of alternatives or mention any exclusions. There is no explicit guidance on selecting between this and similar feed/notification tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond those annotations by specifying the returned content (notes, tags, durations) and the hierarchical relationship to playthroughs, helping the agent understand the data model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences, front-loaded with the core purpose and contents, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description sufficiently covers what is returned and how sessions relate to playthroughs and the journal view. It could mention ordering or date-range behavior, but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'game' parameter with accepted formats and examples (coverage 100%). The description adds no additional parameter guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (dated play sessions) and the data they contain (when, how long, notes/tags). It distinguishes itself from sibling write tools like log_play_session by emphasizing existing sessions, but lacks an explicit verb like 'retrieves' or 'lists', which keeps it from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual hints ('what the journal view is built on') that imply this is for reading session history, but it does not explicitly state when to use this tool versus alternatives like get_journal or log_play_session, nor mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: false, idempotentHint: true, and destructiveHint: false, so the agent knows this is a non-destructive, idempotent write operation. The description adds no extra behavioral context beyond what annotations convey, but it does not contradict them either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and target. Every word earns its place, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with good annotations and no output schema, the description is adequate. It covers the action and key parameter semantics. It omits potential details like auth requirements or return behavior, but these are less critical for a straightforward toggle action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates by explaining both parameters: 'numeric user id' clarifies user_id and 'follow or unfollow' clarifies the boolean follow parameter. However, it does not explicitly state which boolean value corresponds to follow versus unfollow, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Follow or unfollow another Backloggd user by their numeric user id.' It uses a specific verb ('follow or unfollow') and a specific resource (user by numeric id), effectively distinguishing it from siblings like get_follows or search_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools such as get_follows for viewing current follows or search_users for finding users, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare destructiveHint=true, the description adds crucial context: 'IRREVERSIBLE' and 'Requires confirmation.' It also clarifies scope to 'your comments,' preventing accidental deletion of others' content. This goes beyond what annotations provide, though it doesn't detail the two-step confirmation process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short, front-loaded statements: 'IRREVERSIBLE,' 'Deletes one of your comments,' and 'Requires confirmation.' Every word earns its place, with the most critical warning stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool, the description covers the essential points: irreversibility, ownership, and confirmation. The schema's confirmation_token description fills in the two-step process, and annotations convey the destructive nature. It lacks explicit return value details, but that is not expected given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific guidance. The schema covers confirmation_token thoroughly but leaves comment_id undocumented (50% schema coverage). The description does not compensate for this gap, offering only 'your comments' as a marginal hint toward comment_id's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and the resource ('one of your comments'), which is specific and differentiates it from sibling tools like delete_list or delete_playthrough. The title reinforces this with 'Delete a comment (irreversible).' This is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives, but the phrase 'Deletes one of your comments' implies it is for removing your own comments. 'Requires confirmation' hints at the required flow. However, no exclusions or alternative tools are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the fact that filters use Backloggd slugs, which is a small behavioral/input detail, but it does not disclose response format, pagination behavior, or rate limits. Given the annotations, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, and the second sentence efficiently explains slug usage. No redundant filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filter-based browsing tool with no output schema, the description gives a good conceptual model and examples. It would be stronger if it explicitly mentioned pagination or the return format, but the tool is simple and the annotations cover safety. The description is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), and the schema already explains genre and platform slugs. The description reinforces that sort order and filters are the main interaction pattern but does not add significant meaning beyond the schema. It slightly clarifies combination of filters through examples, but this is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: discover games by sort order and filters, explicitly contrasting with title-based search. This distinguishes it from siblings like search_games and get_game, and the examples ('popular RPGs from 2022') illustrate concrete use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when browsing/filtering the catalogue rather than searching by title. It gives illustrative scenarios but does not explicitly name alternative tools like search_games, so it lacks full when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already define the tool as not read-only and not destructive. The description adds that the list is empty initially and references a follow-up action, but it does not disclose other behavioral traits such as duplicate handling, permissions, or side effects. This adds some context beyond annotations but is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the key action front-loaded. Every word contributes meaning without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description adequately explains the purpose and next step, with full schema coverage and annotations providing safety information. It is complete enough for an agent to invoke correctly, though it could mention the returned object or validation rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all three parameters, so the baseline applies. The description does not add any parameter-specific meaning or details beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new, empty game list' with a specific verb and resource. It also distinguishes from the sibling tool add_game_to_lists by instructing to use that afterward to populate, differentiating the creation step from population.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by advising 'Use add_game_to_lists afterwards to populate it', which establishes the sequential workflow. However, it does not explicitly mention when not to use this tool or compare with other alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, non-destructive, and open-world behavior. The description adds the return format (numeric user ids) and the intended downstream use (set_follow_user), which is useful context, but it does not cover details like authentication, rate limits, or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The purpose is front-loaded, and the mention of set_follow_user in the second sentence justifies the tool's existence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional parameters and no output schema, the description sufficiently explains the return value (numeric user ids) and the core functionality. It lacks details on pagination response structure, but the page parameter and schema cover the basics, making it adequate given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (page and username have descriptions; direction only has an enum). The description's phrasing 'who follows them' loosely maps to the direction parameter, adding some meaning, but it does not explicitly explain the direction values or how pagination works. Baseline is 3 given the moderate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves follow relationships (following/followers) and explicitly connects it to set_follow_user by noting it returns the numeric user ids needed for that operation. This distinguishes it from sibling tools like get_user_profile and set_follow_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating the output is what set_follow_user needs, implying when to use this tool. However, it does not explicitly mention when not to use alternatives or provide exclusions, falling short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by specifying 'chronological' order and the data dimensions (played, when, platform), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys essential meaning without redundancy. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return content conceptually ('what they played, when, on which platform'). It's sufficient for this simple tool, though naming alternative tools would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'page' and 'username' already having clear descriptions. The tool's description adds no parameter-specific detail, but the schema fully carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a 'chronological play journal' with specific content ('what they played, when, on which platform'), distinguishing it from siblings like get_play_sessions or get_game_logs. The title reinforces the action (Get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (view a user's play journal) but gives no explicit when-to-use or alternative guidance. With many sibling tools that could overlap (e.g., get_play_sessions, get_game_logs), naming alternatives would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a meaningful behavioral detail: if username is omitted, it defaults to the authenticated user. This goes beyond the schema and annotations by clarifying the default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the core purpose and immediately adds the key default behavior, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and no output schema, the description is adequately complete. It covers the default user behavior and implies the return is a list of reviews, which is sufficient given the low complexity and strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both page and username parameters fully documented. The description adds minimal parameter-specific value, mostly restating the username default that is already in the schema. The baseline of 3 applies because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves reviews written by a user, with the verb 'get' and a specific resource. It also distinguishes its scope from the sibling tool get_game_reviews by focusing on reviews authored by a user rather than reviews for a game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by noting the default is the authenticated user's own reviews, implying it is used for viewing a user's review history. However, it does not explicitly state when to use this tool over alternatives like get_game_reviews or get_activity, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide clear safety signals: readOnlyHint false, destructiveHint false, idempotentHint true. The description adds no additional behavioral context beyond these annotations (e.g., whether it overwrites an existing rating, auth requirements, or side effects). It does not contradict annotations, but it also does not enrich the behavioral profile beyond what structured data provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose and scale, the second adds a crucial warning. Every word earns its place; there is no fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with good annotations and no output schema, the description is adequate. It does not explain the return value or whether the rating is upserted, but the idempotentHint annotation covers idempotency. A short note on behavior on existing ratings would improve it, but overall it is complete enough for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described ('Game title, slug, or numeric Backloggd id' and '0.5 to 5, in steps of 0.5'). The description adds meaningful extra context by warning 'do not pass Backloggd's internal 1-10 value', which is not present in the schema. This clarifies the expected value domain and prevents a common mistake.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Rate a game from 0.5 to 5 stars, in half-star steps.' It specifies both the action (rate) and the resource (a game), and the half-star detail distinguishes it from other rating-like tools. The additional note about not passing internal 1-10 values further clarifies the intended input, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a star rating needs to be set) but does not explicitly mention alternatives or exclusions. Sibling tools like 'remove_rating' for deleting a rating or 'set_game_status' for status changes are not referenced. The guidance is primarily about how to use the tool (the scale) rather than when to choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the scope of 'one game' and the inclusion of 'your own log entry', which is valuable context beyond the structured annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the purpose ('Full metadata for one game') and then enumerates the contents. Every word contributes, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the detailed schema, and annotations, the description fully conveys what the agent can expect. It specifies the output contents (metadata + personal log) and aligns with the read-only behavior. No output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes both `game` (title, slug, or ID) and `include_my_log` (rating, shelf, playthroughs, review). The description does not add additional parameter-level meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full metadata for one game, listing specific fields and adding 'your own log entry'. This distinguishes it from siblings like search_games (looking up games) or get_games_metadata (plural metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: it's for fetching a single game's details with optional personal log. Does not explicitly mention when to use alternatives like get_game_reviews or get_my_game_log, so lacks exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds value by revealing exactly what data is included (shelf, rating, like state, playtime, playthrough details), which helps the agent set expectations. It does not contradict annotations, and no further behavioral caveats are necessary for this simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs all essential information without any fluff. It immediately states what the tool does and what the response contains. Every word earns its place, and the structure is front-loaded with the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, a high-quality schema, strong annotations, and no output schema, the description is sufficiently complete. It tells the agent what the return value contains (the full log components), which is the main missing piece since no output schema is available. The description fully covers the tool's behavioral contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single 'game' parameter, including a detailed description of accepted formats (title, slug, or ID). The tool description does not add parameter-specific meaning because the schema already fully explains it. Per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Your complete log for one game,' and enumerates the specific content (shelf, rating, like state, playtime, every playthrough with review and dates). This specific verb-resource combination distinguishes it from sibling tools like get_play_sessions (which focuses only on sessions) and get_game (which may be metadata only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'complete log for one game' implicitly suggests using this when you need a comprehensive view of a single game's log, but it does not explicitly state when to use it over alternatives like get_play_sessions or get_game_logs. There is no mention of exclusions or specific scenarios, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds the 'public' nature of the profile, implying no authentication required, and lists the fields returned, though it does not describe error handling or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One-sentence description, concise and front-loaded with the key output fields; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one optional parameter and no output schema; the description sufficiently explains the return contents (bio, favorite games, counts) and annotations cover safety, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (username) is fully documented in the schema with 'Backloggd username. Defaults to the authenticated user.' The description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool retrieves a public user profile with bio, favorite games, and play/backlog counts, distinguishing it from siblings like get_user_reviews and search_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives; the context is implied by the description's content but no exclusions or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a 60-per-request limit and that no follow-up lookups are needed, adding context beyond the readOnlyHint and destructiveHint annotations. It does not contradict the annotations, and the idempotentHint=false does not appear in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack the main behavior, use case, and input sourcing with no wasted words. It is front-loaded with the core function and follows with practical guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description conveys what the response includes (games with shelf/rating), the page limit, and the fact that no extra lookups are needed. It lacks explicit mention of the page parameter, but the overall picture is sufficient for a read-only browse tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds key context for the company parameter (where to get slugs) and hints at pagination behavior (60 per request), but the sort and order parameters are left undocumented. With schema coverage at 50%, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns every game by a developer or publisher, each with the user's shelf and rating. This specific verb+resource pairing distinguishes it from the sibling browse_games, which is not company-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides use cases (finding unplayed games, franchise gap-hunting) and tells where to get company slugs (get_game or company links). It lacks a direct contrast with browse_games, but the use-case context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint, so the safety profile is known. The description adds valuable behavioral detail beyond annotations: unmatched names are reported as not_found rather than failing the batch, and it lists exactly what information is returned (shelf, completion, rating, lists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the main purpose. It provides concrete details and a practical example without any filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: read-only batch lookup with two well-documented parameters. The description covers purpose, output items, and edge-case behavior (not_found). It does not explain the return format, but no output schema exists and the described items (shelf, completion, rating, lists) are sufficient for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (games and include_lists). The description does not need to explain parameter mechanics in detail; it adds context about the included data (custom lists) but no significant additional semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific detail: given a list of game names, report shelf, completion status, rating, and custom lists. It distinguishes itself from sibling tools by emphasizing the batch nature and the specific use case of checking many games at once against the user's account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool with the example 'here are 20 games, which do I already have?' and indicates it is built for batch checking. It does not explicitly mention alternatives or when not to use it, but the batch-oriented use case is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it reports every custom list, indicates a boolean containment check, and reveals the output purpose (list IDs for add_game_to_lists). Annotations already declare readOnlyHint=true and destructiveHint=false, so the description complements rather than contradicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core behavior and followed by a practical output note. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives a reasonable overview of what is returned: lists and whether they contain the game, plus the list IDs for downstream use. It is sufficient for a simple read-only tool, though it could explicitly outline the response structure for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for both parameters is 100%, with the game parameter fully describing accepted formats (title, slug, numeric ID) and only_containing explaining its filter. The description adds no parameter-specific details beyond the overall behavior, so it does not elevate semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Report every one of your custom lists and whether it contains this game,' specifying a distinct verb (report) and resource (custom lists with containment status). It differentiates from sibling tools like get_lists by focusing on game membership, and even ties to add_game_to_lists by returning needed list IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to check which custom lists contain a specific game. It implicitly distinguishes from alternatives like get_lists (which likely lists all lists without game filtering) and hints at a workflow with add_game_to_lists, though it does not explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so safety is clear. The description adds behavioral context by explaining that filters accept plain names and that this tool provides the exact list, giving the agent a better mental model of the tool's output and its role in the broader workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a distinct purpose: stating what the tool returns, when to use it, and clarifying the relationship with plain-name filters. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reference tool with low complexity, the description is complete enough. It covers purpose, usage context, and output nature. No output schema exists, but the description makes it clear the tool returns a list of accepted values. Its role among sibling tools is well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'search' parameter with a clear description. The 'kind' parameter is an enum but lacks a description; the tool description partially compensates by stating 'platform and genre,' which maps directly to the enum values. However, the description does not elaborate further on how to use the parameters, and schema description coverage is only 50%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns the accepted values for platform and genre filters. It distinguishes itself from sibling tools by positioning itself as a reference tool for validating or checking filter values before querying, rather than a data-fetching tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Useful when a filter was rejected, or to check whether a platform exists before querying.' This clearly indicates when to use the tool, though it doesn't explicitly name alternative tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context by implying that the search results do not include numeric IDs, hence the need to pair with get_follows. This is a useful limitation that goes beyond the structured annotations, though it does not disclose other behaviors like pagination or match semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. The first sentence states the core purpose, the second gives a practical workflow hint. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description covers the essential behavior (find users by name) and provides a completion step (get_follows for numeric IDs). It lacks explicit output format details, but given the tool's simplicity and the read-only annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does clarify that 'query' is a user's name, adding semantic meaning beyond the generic parameter name. However, it lacks details about matching behavior (partial/exact), case sensitivity, or any example, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Find Backloggd users by name.' This clearly distinguishes it from sibling search_games and other user-related tools. It also adds a workflow hint (pairing with get_follows) that reinforces the purpose of returning user name matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends pairing with get_follows to obtain numeric IDs, which provides clear context for a common workflow. It does not explicitly exclude alternatives or state when not to use it, but the user-name focus and sibling context make the appropriate usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds valuable behavioral context: it pages to exhaustion, returns a compact list, and reports how many pages were fetched and whether the cap truncated the result. This discloses the pagination and truncation behavior beyond what annotations contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and each sentence adds value: the first states the action and result, the second provides usage guidance with examples, and the third reports on output metadata. It is front-loaded with the primary purpose and contains no filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: what the tool does, when to use it, the pagination and truncation behavior, and hints at filtering. It also implicitly addresses cost by mentioning how narrowing can reduce requests. Since there is no output schema, the description's mention of a 'compact list' and reporting of pages fetched provides a reasonable picture. Minor gaps: it doesn't list all filter parameters explicitly or detail response structure, but the schema and enums fill some of that in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (username and max_games have descriptions). The tool description mentions 'a genre filter' as an example but does not explain each filtering parameter. It frames some parameters as 'filters' but leaves their formats ambiguous (e.g., release_year is a string without format details). The description does not compensate sufficiently for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to page a library query to exhaustion and return a compact list of every match. It distinguishes itself from single-page queries by explicitly saying 'rather than a single page', and provides concrete example queries ('which of my backlog are space sims') that make the resource and scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when you need to reason over the entire set... rather than a single page.' It also gives practical advice on narrowing with filters first, even including an example of how a genre filter can reduce the number of requests. This clearly positions it relative to alternatives like query_library despite not naming them directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent, non-destructive write operation. The description adds meaningful context by revealing the 'one call' combined add/remove capability and the dependency on get_lists for IDs. It does not contradict annotations and provides useful behavioral details beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence front-loads the core functionality (add/remove in one call), and the second provides a crucial dependency (get_lists). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with 3 parameters and no output schema, the description covers the essential behavior, the source of list IDs, and the combined operation. Annotations and schema handle safety and types, so the description is sufficient, though it does not mention error handling or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage (only 'game' described), the description compensates by explaining that list IDs come from get_lists and that add/remove lists can be used together. While parameter names are self-explanatory, the description adds valuable guidance on sourcing IDs and combining operations, though it could be more explicit about semantics of the two list parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a game to lists and/or remove it from others in one call.' It specifies the resource (game lists) and the dual add/remove behavior, distinguishing it from sibling tools like create_list or delete_list by focusing on modifying membership in existing lists. The mention of get_lists as the ID source further clarifies its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: list IDs come from get_lists, so this tool should be used after fetching lists. It also signals that add and remove can be combined in a single call. However, it does not explicitly state when not to use it or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, open-world, etc.), the description discloses significant behavioral traits: server-side vs local filtering, cost structure (one request per list page plus one per shelf page), and output annotation. This adds valuable context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, capability, rationale, cost, and alternative. It is front-loaded with the main action and includes no filler or repetition. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return includes provenance annotations but not exact fields. It covers complexity (filtering behavior, cost, alternative) well for a search tool, though a bit more detail on response format would be ideal. Still highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate by explaining parameter meanings. It offers only indirect hints (shelf/list halves, page costs) without detailing genre, max_games, include_lists, or release_platform. This leaves most parameter semantics unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds games across shelves and custom lists simultaneously, with provenance annotation. It explicitly differentiates from query_library by noting the heavier cost and recommending query_library for shelf-only queries, making it highly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance. It explains that list pages lack filters, necessitating this tool for combined shelf+list searches, and directly advises using query_library when shelves suffice. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description adds value by detailing the username behavior (full log history including every replay) and the optional filters (friends-only, rating). No contradiction with annotations; the idempotentHint false is not addressed but doesn't conflict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and each sentence provides necessary information. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 5 parameters and no output schema, the description adequately covers the main modes and filters. It doesn't mention pagination, but the schema documents the page parameter. The 'every replay' detail adds useful context for the username variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 60% of parameters, but the description adds meaning to the undocumented ones: 'friends-only' and 'filtered by rating' clarify the boolean and numeric params. It also elaborates username semantics ('full log history', 'every replay') beyond the schema's 'instead of community logs'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns community logs for a game, with optional friends-only or rating filters, and supports username-based personal logs. This specific verb+resource ('Logs of a game') distinguishes it from other tools like get_game or get_my_game_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: for community logs, or with username for one person's full log history. It does not explicitly mention alternatives or exclusions, but the guidance is clear enough for a straightforward read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses crucial behavioral traits: omitted fields retain current values, unspecified shelves are preserved, and passing playthrough_id edits rather than creates. This directly explains partial-update semantics and the create/update switch, which are important for a write tool and are not visible in the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every phrase adds value. It efficiently conveys scope, partial-update behavior, shelf preservation, and the edit path without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter write tool with no output schema, the description covers the core behavior, update mode, and preservation semantics well. It does not explain the return value or error conditions, but the essential decisions for an agent—what to call, what parameters mean at a high level, and how to avoid overwriting—are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 62%, and the description adds meaningful semantics by grouping parameters ('rating, review text, completion status, play dates and playtime') and explaining that omitted fields keep current values. However, it does not explicitly describe all undocumented parameters such as is_replay, is_mastered, or review_has_spoilers, relying on the schema for those details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Write a full log for a game' and enumerates the exact contents (rating, review text, completion status, play dates, playtime), which is a specific verb+resource description. It also explicitly covers the update mode with playthrough_id, distinguishing this full-log tool from siblings like rate_game, log_play_session, or save_review_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear internal guidance for create versus update ('Pass playthrough_id to edit an existing log instead of adding one'), but it does not explicitly state when to prefer this tool over sibling tools such as log_play_session or rate_game. The intended use is implied by the phrase 'full log,' but exclusions and alternatives are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive (destructiveHint=false) and idempotent operation. The description adds that existing sessions and shelf state are preserved, reinforcing the non-destructive nature, and clarifies the dependency on an existing playthrough. No contradiction with annotations, and the added context is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, followed by essential context. Every word earns its place, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description provides sufficient context: what it does, the playthrough prerequisite, and non-destructive behavior. It doesn't detail every parameter or return value, but the schema covers those, and the tool's purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the description doesn't need to explain every parameter. It adds meaning by summarizing the core purpose (date, duration, note) and explicitly connecting playthrough_id to existing playthroughs. This complements the schema without redundant repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') and clearly identifies the resource (a play session) with its scope (particular date, optional duration and note). It further distinguishes itself from siblings by noting it attaches to an existing playthrough and pointing to get_play_sessions for IDs, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use it: you need an existing playthrough, and get_play_sessions provides the IDs. It implies this is for adding to an existing playthrough rather than creating a new one, though it doesn't explicitly state when not to use it or name alternative tools. This is sufficient guidance for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-call confirmation workflow ('call once without a token to see what would be removed'), which is not captured in annotations, and clarifies that destruction is scoped to the rating only. This adds significant behavioral context beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core purpose and effect, the second gives a critical usage instruction. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description covers the essential confirmation flow and clarifies that the game remains in the library. Combined with detailed parameter descriptions and annotations, it is almost complete, though it does not mention edge cases like attempting to remove a non-existent rating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'game' and 'confirmation_token' are fully described in the input schema, including the token's purpose. The description reinforces the token flow but adds no new parameter-level meaning, meeting the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') with a clear resource ('your rating for a game') and adds scope ('keeping the game in your library'), which distinguishes it from the sibling tool 'remove_game_from_library'. This unambiguously states 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'keeping the game in your library' implies the differentiation from removing the game entirely, providing clear context for when to use this tool. However, it does not explicitly name alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false. The description adds behavioral details: include_my_status costs one extra request for the whole result set and reports your own rating/shelf, which involves user-specific data. This goes beyond annotations and schema, improving transparency. It lacks pagination details but provides meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded purpose, no redundant language. Each sentence adds information: purpose, return fields, and optional behavior with cost. Efficiently structured without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description covers return fields, the optional include_my_status behavior, and its cost. It does not mention pagination or sorting, but limit is in the schema. Annotations cover safety. Adequately complete, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers query and include_my_status but not limit (67% coverage). The description adds meaning to include_my_status by explaining the extra-request cost and the returned fields (rating, shelf). It does not explain limit, but limit's constraints are self-explanatory from the schema. Overall, the description enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Backloggd's game catalogue by title' with a specific verb, resource, and scope. It also lists returned fields (id, slug, year, platforms, category), which distinguishes it from broader browsing tools like browse_games. This is a clear and specific purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for title-based searches of the global catalogue, which is clear context. However, it does not explicitly name alternatives or state when to prefer this over browse_games or query_library, so it lacks explicit exclusions. Clear enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds valuable context: using 'none' preserves rating/review/logs, and the tool reads the current state and only changes what differs. This aligns with the idempotentHint and provides concrete side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and every sentence earns its place: the first explains what the tool does, the second covers an important edge case and idempotency behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with complete schema and annotations, the description adequately covers the primary behavior, the special 'none' case, and the idempotency guarantee. Without an output schema, it appropriately focuses on inputs and side effects, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters with 100% coverage. The description adds meaning by explicitly stating the effect of status='none' on existing data and clarifying the state-delta behavior, which enriches the semantic of the status parameter beyond the enum listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: moving a game to one of the user's shelves, with explicit shelf names and the special 'none' value. However, it does not explicitly distinguish from sibling tools like set_played_status, though the shelf context makes the purpose distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives specific guidance for using 'none' to remove a game from all shelves without deleting rating, reviews, or logs, and notes that the tool is safe to call repeatedly. It lacks explicit comparison to alternatives like set_played_status, but the usage context for the primary operation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds valuable behavioral context by specifying the prerequisite and the exact allowed statuses, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. The first sentence carries the main purpose and status options; the second adds the essential precondition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers purpose, status values, and a precondition. It doesn't explicitly contrast with 'set_game_status', but the played-shelf requirement and the phrase 'how you finished' make the distinction clear enough. A brief mention of when not to use could push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only the 'game' parameter, leaving 'status' with just an enum. The description compensates by listing all status values in prose and linking them to the intended meaning, while also adding a constraint on the game parameter (must be on played shelf). This adds meaning beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair ('Set how you finished a played game') and enumerates all valid statuses. It distinguishes itself from the sibling 'set_game_status' by focusing on completion sub-statuses and the played-shelf precondition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the prerequisite ('The game must already be on your played shelf'), implying when the tool is appropriate. It does not explicitly name alternatives or exclusions, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already indicating non-readonly and idempotent behavior, the description adds crucial context: the hard limit of five favourites, rejection of a sixth, and the lack of a removal endpoint. These details go beyond the annotations and help the agent anticipate failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each carrying distinct information: the action, the limit with consequence, and a note about removal. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter write tool with annotations and a clear schema, the description covers the operational constraints and behavioral expectations completely. No output schema is present, so not describing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single 'game' parameter with its accepted formats (title, slug, or ID). The description adds no additional parameter guidance, so a baseline score of 3 is appropriate given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Pin') and resource ('game to the favourites row on your profile'), clearly distinguishing it from sibling tools like add_game_to_lists. The action is unambiguous and accurately reflects the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by noting the five-favourite limit and that removal isn't supported through the server, implying this is the only way to add via API and removal must be done manually. However, it doesn't explicitly name alternatives or state exclusions beyond the removal caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior; the description adds useful context by noting that it reports whether writes are enabled and the current rate-limit state. This goes beyond the annotation hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences pack all necessary information: what it reports and when to use it. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool with no output schema, the description tells the agent what data it will receive and when to call it. Combined with the annotations, it provides enough context to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (100% coverage). The description correctly implies no input is needed, which matches the empty properties schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names the exact resource: the authenticated Backloggd account, write-enablement, and rate-limit state. This clearly distinguishes it from the many game/library/comment tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this first if unsure the server is set up, providing a clear context. It does not state explicit exclusions or alternatives, but as a whoami/status tool alternatives are not obviously relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds the two-call confirmation process, the preview content (list name and game count), and the 'everything in it' scope. This is significant behavioral disclosure beyond boolean hints, especially for an irreversible operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'IRREVERSIBLE,' no wasted words. Each clause adds value: the destructive scope, the confirmation requirement, and the preview behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with a well-documented schema and annotations, the description covers the destructive nature, the confirmation workflow, and the scope, making it complete for an agent to invoke correctly. The absence of an output schema is compensated by the clear preview behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100% with detailed descriptions, and the description summarizes the confirmation flow but does not add new information beyond the schema. The baseline of 3 is appropriate because schema coverage is complete and the schema already explains the token semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Deletes') and resource ('entire list and everything in it'), clearly distinguishing it from sibling create/reorder tools. The title also reinforces irreversibility, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit step-by-step usage for the confirmation workflow: first call without a token, review preview, then call again with the token. It does not explicitly name alternatives, but the destructive context and confirmation instructions provide clear guidance on how to use it safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations: invalid filter values are rejected before the request is sent, an empty result reliably means nothing matched, and sort defaults (e.g., avg-finish-time is LONGEST first). These details help the agent trust empty results and interpret sorting correctly. This goes well beyond the readOnlyHint/openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a core statement, examples, and a reliability note. It is somewhat verbose but every sentence adds value. The sort caveat is repeated in the schema, introducing slight redundancy, but the front-loaded purpose and examples outweigh this.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and no output schema, the description covers the primary usage scenarios, example filters, and edge cases (e.g., empty result meaning, played_platform vs release_platform). It does not detail pagination behavior or return fields, but the page parameter is present in the schema. The description is sufficiently complete for a discovery tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is high (86%), the description adds substantial semantic value: it explains that sort='shuffle' picks at random, indicates that avg-finish-time defaults to longest first, and cautions about played_platform returning nothing on backlog. The examples map user intent to parameter combinations, making abstract enums and fields meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'the main discovery tool' for searching a user's library with 'Backloggd's full filter grammar'. It specifies the resource (library) and action (search), and sets expectations for filtering by shelf, platform, genre, year, status, or rating. This distinguishes it from sibling tools like search_games or browse_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('main discovery tool') with concrete examples (shelf='backlog' + release_platform='PS5', sort='shuffle'). It implicitly differentiates from siblings but does not explicitly name alternatives or state when not to use it. The exclusion on played_platform ('use release_platform instead unless you specifically mean this') is embedded in the schema rather than the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining the draft is account-wide, acts as a scratch buffer behind the site's review editor, and does not publish content. It implicitly conveys idempotent overwriting behavior through the 'scratch buffer' metaphor, although it does not explicitly state that an existing draft is overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences. Each sentence adds distinct value: purpose, scope, and alternative guidance. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with good annotations, the description covers the core purpose, scope, and alternative. It does not mention return values or error behavior, but given no output schema and the straightforward nature of a save operation, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'review' parameter (0% coverage), but the description identifies it as 'review text', which conveys the core meaning. It does not provide details on format, length limits, or overwrite semantics, but for a single string parameter with an obvious name, this is sufficient baseline understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves review text as a draft without publishing, using specific verb and resource. It further distinguishes from sibling log_game by explicitly naming it as the publish alternative, and clarifies the draft's account-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (saving a draft) vs. when to use an alternative ('Use log_game to actually publish a review against a game'). This is a clear exclusion and alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true, but the description adds significant behavioral detail: it specifies exactly what gets destroyed (review and journal sessions) and the preview-and-confirm mechanism. This goes well beyond the annotation's simple destructive flag and clearly explains the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the action and scope, the second provides the essential confirmation workflow. Well front-loaded and free of unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description covers the full scope of deletion and the confirmation process. Combined with the rich schema and annotations, an agent has all necessary context to use the tool safely and correctly, without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the confirmation_token parameter in the schema already explains the two-step behavior in detail. The description adds no new information about the game or playthrough_id parameters, so it doesn't improve on the schema's semantics; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a single playthrough log' – a specific verb and resource – and then clarifies the scope by adding 'including its review and any journal sessions attached to it.' This clearly differentiates it from sibling delete tools like delete_list and delete_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the required two-step confirmation flow: 'call once without a token to see what would be deleted.' This tells the agent exactly when to invoke without a token and that a second call with the token is needed for the actual deletion, which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral traits: 'COSTS ONE REQUEST PER GAME' and 'Results are cached for six hours.' This adds cost and caching context not captured in annotations, which is essential for an agent deciding whether to call this tool repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Each of the four sentences earns its place: purpose, cost warning, usage guidance, and caching behavior. The information is front-loaded and directly actionable, with no filler or repetition. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description still covers the returned metadata fields (platforms, genres, year, rating, playtime), the cost model, caching behavior, and explicit guidance on when to use this tool versus query_library. This is complete context for an agent to select and invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'games' as 'Up to 25 names, slugs or ids' but leaves include_playtime with only a default. The description mentions 'playtime' in the metadata list, hinting at the parameter's role, but does not explicitly explain that include_playtime toggles playtime output. With 50% schema coverage, the description partially compensates but leaves a gap in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pairing: 'Platforms, genres, year, rating and playtime for a set of games.' It explicitly scopes the tool to sets of games and lists the metadata fields. It also distinguishes itself from sibling tools like query_library and get_game by contrasting library queries with custom lists, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'prefer query_library when the set is really a library query' and 'Use this for sets that are not a library query — most often the contents of a custom list.' It even gives an example ('which of my VR list are on Quest 3'), clearly stating when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true, the description adds meaningful context: shelf state is attached to each related game, and 'series' follows IGDB's collection grouping rather than marketing franchise. It explains a subtle behavioral trait that affects interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose: 'Games related to one game — its series, DLC, editions, mods or bundles'. The following sentences add a use case and a critical distinction, each earning its place without redundancy. It is concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-type read-only tool with two simple parameters and no output schema, the description covers the essential aspects: what it returns (related games with shelf state), how to interpret results (IGDB collection grouping), and when to use an alternative. It provides enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the 'series' enum value via the IGDB collection note, but does not explain other section values (dlc, editions, mods, bundles, in-bundle, related/associated). Schema coverage is only 50% (game is described, section only has enum), and the description only partially compensates for the undocumented section options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists games related to a given game (series, DLC, editions, mods, bundles) and attaches shelf state. It directly addresses a specific use case ('does this have a remaster or DLC I don't own'), and the franchise/collection distinction helps differentiate it from browse_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: for checking related content and owning status. It also gives an alternative for broader franchise questions ('use browse_company on the publisher instead') and explains the IGDB collection limitation with a concrete example, making the choice clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark destructiveHint=true and readOnlyHint=false, the description adds crucial context beyond that: the comment is public, not quietly undoable, and requires a confirmation preview. This explains the two-call mutation flow and the risk involved, significantly improving the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both necessary. The first sentence states the purpose and visibility; the second explains the confirmation process. No redundant words, no repetition of schema details, and the front-loading is ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the essential context: visibility, irreversibility, and the two-step confirmation. The annotations and schema already provide safety hints and parameter details. The description is sufficient for an agent to use the tool safely, including the critical preview step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), so the description must compensate. It does add meaning for the 'target' parameter ('on someone's review or list') and explains the 'confirmation_token' workflow ('call once without a token... then call again with the token'). However, it adds little for 'body' and 'target_id', whose semantics are inferable from names and schema constraints. Overall, it compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Post a PUBLIC comment on someone's review or list, under your username.' This uses a specific verb and resource, and the public nature distinguishes it from related tools like like_review or delete_comment. It fully 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage steps: call once without a token to preview, then call again with the token after user agreement. This is strong practical guidance. It does not explicitly mention alternatives or when not to use, but the two-step confirmation is a clear workflow that overcomes the absence of alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, but the description goes far beyond by listing all destroyed data types, stating there is no undo, and detailing the required confirmation token flow. This rich context is essential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'IRREVERSIBLE.' and the full impact list. Every phrase is necessary and actionable; no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully captures the tool's destructive nature, the preview-then-confirm flow, and the expected behavior of the confirmation token. An agent has all needed information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is described. The description adds value by explaining the confirmation_token's role in the two-call workflow, reinforcing the parameter's semantic purpose beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language ('Wipes everything') and enumerates the exact resources affected (logs, playthroughs, review, rating, track time, library entries, like status). This clearly distinguishes it from narrower sibling tools like remove_rating or delete_playthrough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context: this is for complete removal and irreversibility, and it spells out the two-step confirmation workflow. However, it does not explicitly name alternatives for partial removal, so it lacks an explicit 'when-not' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait not captured in annotations: 'Pass the FULL ordered set of entry ids — anything omitted may be dropped.' This warns about destructive replacement semantics, adding essential context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The first states the core action, the second delivers a critical warning, and the third provides a source and use case. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with complete schema coverage and no output schema, the description covers purpose, usage context, prerequisites, and failure semantics. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics about the 'entries' parameter: it must be the full ordered set and omitted ids may be dropped, going beyond the schema's positional description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set the order of a list's entries, and optionally a note on each.' This is a specific verb+resource pairing that distinguishes it from sibling tools like create_list or delete_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use it ('Most useful for ranked lists') and a prerequisite (entry ids come from get_list). It doesn't explicitly state exclusions or alternatives, but the guidance is sufficient for basic tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![backloggd-mcp MCP server](https://glama.ai/mcp/servers/DenisionSoft/backloggd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DenisionSoft/backloggd-mcp)

Score Badge

Copy to your README.md:

[![backloggd-mcp MCP server](https://glama.ai/mcp/servers/DenisionSoft/backloggd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DenisionSoft/backloggd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DenisionSoft/backloggd-mcp'

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