mastodon-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool targets a distinct resource or action. Even closely named tools like get_status, get_status_source, and get_status_history are clearly differentiated by their descriptions and the noun in the name. No two tools appear to do the same thing.
Naming Consistency5/5
Tool names consistently follow verb_noun snake_case (e.g., post_status, get_followers, unblock_domain). The few exceptions (whoami, search) are single-word, idiomatic, and do not break the overall predictable pattern.
Tool Count1/5
With 76 tools, this is far beyond the typical 3-15 well-scoped range and exceeds the 50+ threshold for an extreme mismatch. Even though the Mastodon API is broad, the sheer number of tools makes selection and context management difficult for an agent.
Completeness5/5
The toolset covers essentially the entire Mastodon API surface: status CRUD and editing, scheduling, interactions (favorite, boost, bookmark, pin, poll), account relationships, blocks/mutes at both account and domain levels, notifications, lists, hashtags, directory, trends, and announcements. It includes both action and inverse-action pairs, leaving no obvious dead ends.
Average 3.8/5 across 76 of 76 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on September 1, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotentHint=true, readOnlyHint=false, and destructiveHint=false, but the description adds no behavioral context beyond repeating the action. It does not mention side effects, error conditions, or account-actor behavior, though it does not contradict 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but the single sentence merely repeats the title and therefore provides no informative content. This is under-specification rather than effective conciseness, unlike a terse but informative summary.
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 mutating tool with no output schema, the description should at least clarify what happens when the status is favourited or what is returned. It does neither. The agent must rely entirely on the schema and annotations, which leaves meaningful gaps around expected outcomes and edge cases.
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 both parameters (id and account) already have meaningful descriptions, so the baseline is 3. The tool description itself adds no parameter-level meaning, but the schema carries the load adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Favourite a status.' is a verbatim restatement of the title, so it is a tautology rather than an independent explanation. It names the resource and action but does nothing to distinguish it from close siblings like bookmark_status or unfavourite_status.
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 about when to use this tool versus alternatives such as bookmark_status or unfavourite_status. There are no exclusions, prerequisites, or contextual cues to help an agent decide between similar status-affecting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context about what the tool returns, whether it supports pagination, or how it handles multiple accounts. The description is essentially a restatement of the title without deeper behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not well-structured. 'Your curated lists.' is vague and uninformative as an opening. The second sentence primarily describes get_list_timeline, which is off-topic for get_lists. The content would be better used as documentation for sibling tools.
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 tool with a single optional parameter and no output schema, the description is still inadequate. It fails to state what the returned data will look like or how to interpret the lists. The reference to get_list_timeline helps a little, but the core function of get_lists is never clearly explained.
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%, and the single 'account' parameter is fully documented in the schema with explanation and defaults. The description adds no extra parameter semantics, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Your curated lists.' is a noun phrase rather than a clear verb-resource statement. It never explicitly says 'get' or 'list' the user's lists, leaving the action implicit. The only actionable hint is redirecting to get_list_timeline, which describes a different tool.
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 gives no explicit guidance on when to call get_lists itself. It only mentions that a list id can be passed to get_list_timeline, which is related but does not clarify the purpose or alternatives for listing lists. No when-to-use or when-not-to-use criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety. The description adds no behavioral context beyond what annotations provide—no pagination details, no mention of default limit, no notes on list ownership or authorization. With annotations carrying the safety profile, the description contributes nothing extra, warranting a score below 3.
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. It is appropriately sized for a simple read operation, though it could be more action-oriented. The structure is clean and front-loaded with the resource being described.
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 read-only tool with annotations and a partial schema, the description minimally conveys the return value (accounts on a list). However, it lacks context about the required id parameter, any default behavior, or how this relates to list management. Given the simplicity, the missing details are not critical but still noticeable; a more complete description would mention the need for a list ID.
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%, with limit and account having inline descriptions, but id is undocumented. The description text itself does not elaborate on any parameters. The id parameter's semantics are predictable from context (list ID), but the description does not compensate for that gap. Since the schema covers most parameters adequately, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The accounts on one of your lists.' is a noun phrase that states the resource but lacks an explicit verb like 'get' or 'list'. It is clear enough from the tool name and title, but the description alone does not convey the action. It does distinguish from sibling tools like get_list_timeline by focusing on accounts, but without explicit action language.
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 mention of prerequisites (e.g., needing an existing list ID), and no exclusion criteria. Sibling tools like get_lists or get_list_timeline are not referenced, so the agent must infer the intended use from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is covered. However, the description adds no additional behavioral context: it does not mention pagination, ordering, result format, or that the list may change as new mutes are added. No value is added beyond the structured 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 a single terse clause with no filler, and it is front-loaded. It is efficient in length, though it borders on under-specification because it provides almost no operational detail beyond the title.
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 read-only paginated list, the schema and annotations cover a fair amount of context. However, there is no output schema, and the description does not clarify expected return shape, ordering, or that it refers specifically to account mutes rather than conversation mutes. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all three parameters (limit, max_id, account) have useful schema descriptions. The tool description itself contributes no parameter-level meaning, so the high schema coverage carries the load and the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the title restated as a noun phrase: 'Accounts you have muted.' It identifies the resource clearly but uses no verb and does not differentiate from sibling list tools like get_blocks or from mute_account. It is understandable, but it adds little beyond what the tool name and title already imply.
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?
There is no guidance on when to use this tool versus alternatives such as get_blocks, mute_account, or get_conversations. The description names no context, no exclusions, and no conditions that would help an agent choose between this and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a mutating, non-destructive, idempotent operation. The description adds nothing beyond the bare fact that the account is unfollowed; it does not disclose edge cases, whether the action is reversible by follow_account, or what happens if the account was not followed in the first place.
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 filler, making it easy to parse and front-loaded with the essential action. It is concise but borders on tautological since it repeats the title almost verbatim, lacking supporting details that would make the sentence more valuable.
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 tool with an undocumented required parameter and no output schema, the description is too sparse. It does not explain what acct should contain, how the operation interacts with the following list, or whether there are side effects such as removing a follow request or affecting muting/blocking state.
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 schema describes the optional 'account' parameter in detail, but the required 'acct' parameter has no description. The tool description only says 'an account,' giving a minimal semantic hint for acct but no information about the expected format (handle, URL, ID), so it does not adequately compensate for the 50% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop following') and the resource ('an account'), and this is distinct from sibling tools like follow_account, mute_account, and block_account. However, it does not explicitly differentiate itself from similar unfollow variants such as unfollow_hashtag, instead relying on the word 'account' to do that work.
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?
There is no guidance about when to use this tool versus alternatives like mute_account or block_account, nor any exclusion criteria. The only implied usage is that the agent should call it when it wants to unfollow an account, but no context or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description itself adds no behavioral context beyond what the annotations and schema provide, such as pagination behavior or the shape of returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of fluff, but it is essentially a repeat of the title 'Accounts you have blocked' and therefore does not earn much of its place. It is concise without being substantively useful.
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 tool with no output schema and a minimal description, an agent lacks context about the return shape and about how this endpoint differs from adjacent list tools like get_mutes and get_blocked_domains. The schema and annotations cover parameters and safety, but not the selection context an agent needs when choosing among similar siblings.
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 each parameter (limit, max_id, account) already has a meaningful description including defaults, pagination behavior, and account matching semantics. The tool description adds no parameter-level meaning, so it correctly stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as blocked accounts, which is immediately understandable and separates it from follower, mute, endorsement, and blocked-domain list tools. It is a noun phrase rather than an explicit verb+resource statement, but the purpose is not vague. It does not explicitly name sibling tools, so it stops short of a 5.
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 gives no guidance on when to use get_blocks versus related sibling tools such as get_mutes, get_blocked_domains, or get_endorsements. There is no 'use this when...' or 'use X instead for...' context, so an agent must infer the usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral context beyond that: no mention of pagination behavior, sorting, rate limits, or what exactly is returned. It merely restates the subject matter.
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 short with no wasted words and the core scope is front-loaded. It is a fragment rather than a complete sentence, but given the tool's simplicity, the brevity is mostly appropriate.
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?
The schema and annotations cover parameters and safety, and the title conveys the operation. However, there is no output schema and the description does not explain what the return value looks like (e.g., a list of domain strings) or how pagination works beyond the max_id hint, leaving minor ambiguity for a listing 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?
Schema description coverage is 100%, so limit, max_id, and account are already fully documented with clear meanings. The description contributes no additional parameter-level nuance, so it sits at the baseline for tools with complete schema coverage.
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 provides a clear verb+resource: 'List instances you have blocked.' The description reinforces the scope with 'Whole instances,' which distinguishes this from per-account or per-user block tools like get_blocks. However, the description itself is a fragment without an explicit verb and does not name any sibling tool.
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?
There is no guidance on when to use this tool versus alternatives such as get_blocks, block_domain, or unblock_domain. The description gives no context about typical use cases, prerequisites, or exclusions, leaving the agent to infer entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which cover the basic safety profile. The description adds no behavioral context beyond that, such as whether pinning replaces a previously pinned status or whether it requires an unpin first. No contradiction exists, but no extra value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it simply restates the title and lacks substantive information. It is concise but not information-dense; it earns its place only barely.
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 two-parameter tool with no output schema and helpful annotations, the description is minimally sufficient. However, it does not explain the effect of pinning on an existing pin, any rate limits, or what the response contains, leaving minor but relevant gaps for a complete usage picture.
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 parameters clearly described: 'id' as the status id and 'account' explaining matching rules and default behavior. The description itself does not mention parameters, but the schema adequately documents them, so the baseline of 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 states a clear verb ('Pin') and resource ('your own statuses') with the location ('top of your profile'). It is distinguishable from the sibling 'unpin_status' by action direction, but the description does not explicitly contrast with other pin-related tools. Still, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites such as needing an existing status or the effect of re-pinning. The description implies the user has a status to pin but offers no decision support or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply idempotentHint=true and destructiveHint=false, and the description adds no behavioral context beyond restating the title. It does not disclose that removing a bookmark is non-destructive to the status, that it is safe to call on an already-unbookmarked status, or any account/authorization implications.
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, front-loaded sentence with zero wasted words. It is appropriately minimal for a simple tool, though it is identical to the title and therefore adds no new information.
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 simple action, thorough schema, and helpful annotations, the essential information for a basic call is present. However, the description does not mention what happens when the bookmark does not exist, whether the underlying status is affected, or what a successful response looks like, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: 'id' is described as 'The status id' and 'account' explains allowed handle formats and default behavior. Since the schema fully documents both parameters, the description's lack of parameter detail is acceptable, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a bookmark.' clearly states a specific verb and resource, making the intent unambiguous. It does not explicitly differentiate itself from sibling tools like bookmark_status or get_bookmarks, so it stops short of a 5.
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?
There is no guidance about when to use this tool versus alternatives, no mention that the status must currently be bookmarked, and no indication that bookmark_status is the complementary operation. The usage context must be inferred entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. Annotations indicate a non-read, idempotent, non-destructive operation, and the description merely restates the action. No context about side effects, idempotency, or account handling is added.
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?
One short sentence with no fluff; the message is immediately understandable. It loses a point because the sentence is identical to the title and therefore does not earn its place as additional descriptive content.
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 two-parameter action with strong schema coverage and informative annotations, the description is minimally sufficient. However, it omits any guidance about output or usage context, so it is only adequate, not 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?
With 100% schema description coverage, the schema already explains both 'id' and 'account' thoroughly. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('status') and directly conveys that this is the inverse of favourite_status. However, it simply restates the title and does not explicitly distinguish itself from sibling tools like favourite_status or get_favourites.
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 gives no indication of when to use this tool rather than favourite_status, unbookmark_status, or other related toggles. There is no mention of prerequisites, context, or alternatives.
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 communicate the key behavioral traits: readOnlyHint is false, idempotentHint is true, and destructiveHint is false. The description adds no additional behavioral context, such as whether unmuting restores notifications or affects existing blocks. It is not contradictory, but it contributes little 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or repetition, making it easy to parse quickly. However, it is so minimal that it largely restates the title without adding useful detail, so it earns high marks for brevity but not maximum utility.
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 tool with one required parameter and no output schema, the description should at least explain what the required 'acct' should contain and what happens after unmuting. It does neither, leaving the agent without enough information to call the tool correctly on its own.
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 50%, and only the optional 'account' parameter is explained. The required 'acct' parameter is entirely undocumented, and the description does not clarify whether it is a username, account ID, or handle, nor how it relates to 'account'. The description fails to compensate for this gap.
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 a specific action ('Stop hiding an account') with a recognizable verb and resource. However, it is nearly identical to the title and does not distinguish this from related sibling tools like unmute_conversation or unblock_account, leaving the differentiation to the reader.
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?
There is no guidance about when to use this tool versus alternatives such as mute_account, unmute_conversation, or unblock_account. The description states only what the tool does, not when it should be chosen or what conditions make it appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal this is not read-only, not idempotent, and not destructive. The description merely repeats 'Create' and adds no new behavioral context—no mention of side effects, whether the list starts empty, authorization requirements, or what the response contains. For a mutating tool, this is a gap beyond what annotations cover.
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 one short sentence plus a practical pointer to add_to_list. It is front-loaded with the core purpose and contains no filler or repetition. Slightly over-concise given the tool has four parameters, but appropriate for a simple creation operation.
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?
The description is adequate for a basic create tool: it names the action and the follow-up operation. However, there is no output schema and no mention of what the call returns or any prerequisite behavior. The workflow hint partially compensates, but an agent might still wonder about response format or required account context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no parameter-specific meaning beyond the generic 'curated list' notion. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a curated list.' It clearly separates itself from add_to_list by pointing to that sibling for the next step, making the tool's role in the list workflow unambiguous. It does not explicitly differentiate from other list tools like get_lists or delete_list, but the primary purpose is clear.
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 a workflow: create a list first, then use add_to_list to populate it. That gives some usage context, but it never states when to choose this tool over alternatives or provides any exclusions. It's an implied usage rather than an explicit guideline.
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, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds no behavioral detail beyond the resource's meaning, such as pagination behavior or auth requirements, but nothing it states conflicts with 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 a single, efficient noun phrase with no filler words. However, it duplicates the title exactly, so it earns no extra credit for providing unique information and lacks a front-loaded action verb.
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 read-only list with documented parameters, the description is minimally sufficient. It does not describe the output shape or item fields, and with no output schema an agent would have to infer the return format from the name and title.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, max_id, and account are fully explained in the schema, including defaults, constraints, and continuation semantics. The description adds no parameter-level information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource ('accounts you feature on your own profile') and the tool name 'get_endorsements' maps directly to it. It is specific enough to distinguish from siblings like get_followers or get_following, though it lacks an explicit verb such as 'list' and repeats the title verbatim.
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?
There is no guidance on when to call this tool rather than the many sibling get_* tools, no stated exclusions, and no mention of common use cases such as retrieving the profile's featured endorsements. An agent must infer the context entirely from the name and title.
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, idempotentHint, openWorldHint, and destructiveHint. The description adds valuable context about federation: the result is limited to the local instance's knowledge, which directly explains the openWorldHint and is critical for setting expectations. This goes beyond the structured annotations and enhances behavioral understanding.
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 two short sentences, with the core entity stated first and the federation caveat as a supplementary clause. It is efficient and front-loaded, though the first sentence is a noun phrase without a verb. Still, it earns high marks for brevity and clarity.
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?
The tool lacks an output schema, so the description must explain what is returned; it does state 'accounts that favourited a status', which is a reasonable high-level return. However, it does not mention the required 'id' parameter, nor does it describe pagination or any response structure. The federation context helps, but gaps remain for a straightforward API call.
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 does not mention any parameter, and only two of three parameters have schema descriptions (limit and account). The required 'id' parameter lacks both schema description and any clue in the description about identifying the status. Schema coverage at 67% is partial, and the description fails to compensate for the missing id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: accounts that favourited a status. The title 'See who favourited a status' reinforces the action, and the federation caveat distinguishes this from a universal list. It is specific enough to separate from siblings like get_boosted_by, though it lacks an explicit verb in the main sentence.
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. It mentions federation's limitation but does not state when it should be chosen over get_boosted_by or get_favourites. No exclusions or context signals are given, leaving the agent to infer usage from the name and title.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety traits. The description adds useful context about the mechanics of following hashtags but does not disclose return format, pagination, or error behavior. Since annotations cover the core safety profile, the marginal behavioral information is modest, warranting a baseline 3.
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 short and front-loaded, starting with the direct statement 'Hashtags you follow.' The contextual explanation about feed-building is relevant but could be trimmed; still, every sentence contributes meaningful background. It is not overlong, earning a solid 4.
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 the tool's simplicity, the rich annotations, and fully documented parameters, the description is mostly complete. It explains why the tool matters (building a feed without an algorithm) and why it is distinctive. There is no output schema, so not explaining return values is acceptable. Minor gaps like pagination or error conditions are not critical for a read-only list endpoint.
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 two parameters: limit with constraints and default, and account with matching rules and default. The description adds no additional parameter detail beyond what the schema already documents. Per the calibration baseline, a 3 is appropriate when the schema carries the semantic load.
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 'List hashtags you follow' and description's first phrase 'Hashtags you follow' clearly indicate the tool's function. The description also differentiates it by noting that no existing Mastodon MCP server exposes this, which helps distinguish it from related tools like follow_hashtag or unfollow_hashtag, though the purpose is stated rather than a full imperative sentence.
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 explains the purpose of following hashtags (bringing public posts into the home timeline) but provides no guidance on when to call this tool versus alternatives such as get_hashtag_timeline or search. It does not state any exclusions, prerequisites, or context in which this tool should be preferred, leaving the agent without a clear decision rule.
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 and idempotentHint=true, so the safety profile is known. The description adds the semantic effect (notifications are re-enabled for the thread) but doesn't disclose any additional behaviors like whether it's a no-op when already unmuted or what happens to existing notifications. Given annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, which is very concise. However, it is a verbatim repeat of the title, so it does not earn its place by adding new information. It is not bloated, but it is redundant.
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 the tool's simplicity, two fully described parameters, and annotations covering idempotency and non-destructiveness, the description is nearly sufficient. It clearly states the outcome (notifications resume). The main missing piece is explicit linkage to mute_conversation as the inverse operation, but that is inferable from the sibling name.
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 'id' and 'account' described. The tool description adds no parameter-specific information, so the schema carries the full burden. Per the baseline rule for high coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start being notified about this thread again' clearly states the tool's effect: re-enabling notifications for a specific thread. It uses a concrete verb phrase and indicates the resource (the thread). However, it is identical to the title and does not explicitly differentiate this from mute_conversation or other sibling tools, so it stops short of a 5.
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 such as mute_conversation or get_conversations. It does not mention any preconditions, exclusions, or preferred use cases. An agent must infer from the sibling list and schemas.
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 mark the operation as non-read-only, non-idempotent, and open-world, so the description only needs to add context; it adds the key precondition that the status must not have published. It does not describe error behavior or side effects, but that is acceptable for a simple cancel 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?
One tight, front-loaded sentence with no filler or repetition of schema fields. Every word contributes to the action and the boundary condition.
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 two-parameter mutation with annotations and a detailed account field, the description is mostly sufficient; the missing id semantics and the lack of a pointer to list_scheduled_statuses are the main gaps. No output schema exists, so not documenting return values is not a penalty here.
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 account parameter is well documented in the schema, but the required id parameter has no description and the tool description never states that id is the scheduled-status identifier from list_scheduled_statuses. At 50% schema coverage, the description does not compensate for the gap.
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?
States a clear verb and resource ('Cancel a status that was scheduled') and adds the scope qualifier 'has not published,' which separates it from deleting a published status. It does not name or explicitly contrast sibling tools, so it stops short of a 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 implies the intended use: for a scheduled status that has not yet published, and its wording excludes already-published statuses. It does not explicitly tell the agent when to prefer this over reschedule_status or to obtain the id via list_scheduled_statuses.
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 cover idempotency and non-destructive mutation; the description adds the user-visible effect of stopping timeline posts. It does not mention reversibility, permissions, or other side effects, so it adds only modest context 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?
A single, front-loaded sentence expresses the core action with no wasted words or repetition of the title.
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?
The tool is simple, and annotations cover idempotency and non-destructive behavior, but the missing hashtag parameter format and the absence of output/response guidance leave a few gaps. Overall it is adequate but not fully 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 50%; the account parameter is well documented in the schema, but the required hashtag parameter has no schema description. The description merely says 'a hashtag's posts' and does not clarify the accepted string format, such as whether the leading '#' should be included.
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 uses a specific verb ('Stop') and resource ('a hashtag's posts appearing in your home timeline'), making the operation clear. It does not explicitly name sibling alternatives like follow_hashtag, so it stops short of full sibling differentiation.
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 intended use is implied: use it when you no longer want a hashtag's posts in your home timeline. It does not explicitly provide when/when-not guidance or point to related tools like follow_hashtag or get_followed_hashtags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Remove' and 'This is not undoable,' both implying permanent deletion of a resource. The destructiveHint annotation is false, which signals a non-destructive operation. This is a direct safety-signal contradiction, so the description fails the behavioral transparency check.
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 compact sentences with no filler. The operation is stated first, followed immediately by the important irreversibility warning.
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 dismiss action, the core effect and irreversibility are present, but the description does not clarify what id should contain or what happens on repeated dismissal, especially with idempotentHint false. The conflicting destructiveHint annotation further undermines completeness.
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 50%: account is documented in the schema, but the required id has no description and the tool description never states that id is the notification to dismiss. The description adds no parameter-level meaning beyond what the schema already provides.
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 ('Remove') with a specific resource ('a single notification from the list'). The word 'single' distinguishes it from clear_notifications, and the focus on one notification clearly separates it from read-oriented notification tools.
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 clearly indicates this tool is for dismissing one notification at a time, giving an agent a direct condition for use. It does not explicitly name clear_notifications as the alternative for bulk removal, so it stops short of full alternative routing.
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 cover read-only, open-world, and idempotent behavior; the description's 'as far as your instance knows' mostly restates the openWorldHint rather than adding new behavioral context. 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?
One sentence that front-loads the result ('accounts that boosted a status') and appends the key open-world caveat. No 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 read-only list operation, the definition is complete: the required status id is inferable, limit and account are schema-documented, and no output schema is needed to understand an account list. It could mention response shape or pagination, but this is not a major gap.
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 limit and account well, and the description's 'a status' makes the required id refer to a status ID. Still, the description itself adds no parameter detail beyond the schema, and the undocumented required id is only implicit.
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 states exactly what the tool returns: 'the accounts that boosted a status', and the title mirrors it. It doesn't name the sibling get_favourited_by, so it lacks explicit differentiation, but the operation is unmistakable.
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 about when to call this instead of get_favourited_by or get_status_history. 'As far as your instance knows' hints at a limitation but not a decision rule.
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 convey the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description does not need to restate it. The description adds no behavioral context beyond the action itself, but it does not contradict 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 concise sentence with no filler and the action is immediately clear. It earns its place 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 two-parameter tool with no output schema, the description plus schema is largely sufficient for an agent to invoke it correctly. It could have noted the inverse relationship to boost_status, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the id and account parameters. The description adds no parameter-level meaning, which is acceptable given the high schema coverage baseline.
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 states a clear verb and resource: 'Undo a boost' tells the agent it removes a boost from a status. It is not vague, though it repeats the title and does not explicitly differentiate itself from the sibling boost_status beyond the inverse phrasing.
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 provided about when to use this tool versus alternatives. The inverse relationship to boost_status is implied by 'Undo,' but the description never tells the agent when to select this over other status actions or what prerequisites apply.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the ordering behavior ('newest first') and a tip about reply filtering, which is useful but not extensive. It does not mention pagination mechanics, default limits, or authentication requirements, though these are partly in the schema. No contradiction with 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 two sentences, with the core purpose front-loaded. The second sentence adds a practical tip without excess. It is appropriately concise and well-structured, though it could arguably be expanded slightly with pagination behavior or a mention of the 'account' parameter's default.
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 10 parameters fully described in the schema, the description covers the essential context: what it returns (account statuses) and ordering. It does not explain the return format, but no output schema exists. The automatic pagination and parameter defaults are in the schema, so the description is adequate given the annotations and schema richness.
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%, so the schema already documents all 10 parameters. The description adds minimal semantic value beyond the schema: it highlights 'exclude_replies' with a use case and notes 'newest first' (not a parameter but ordering). This is a marginal enhancement over the baseline 3 for full schema coverage.
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 states the core function clearly: 'Statuses by one account, newest first.' This specifies the verb (get statuses), the resource (one account), and the ordering. It distinguishes from get_account (account details) and timeline tools by focusing on a single account's posts, though it does not explicitly name those alternatives.
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 a specific usage tip: 'Use exclude_replies when studying how someone writes, so replies do not dominate the sample.' This provides context for when to use a parameter, but it does not explicitly state when to choose this tool over alternatives like get_home_timeline or get_account. It implies the use case of examining an account's own posts but lacks exclusions or alternative routing.
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: 'Pages automatically past the 40-per-request ceiling,' which tells the agent that pagination is handled and multiple requests may occur transparently.
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 core purpose is stated first, and the pagination behavior is added as a second valuable sentence. Every word earns its place.
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 read-only listing tool, the description is mostly adequate, especially with annotations covering safety. However, with no output schema, it does not describe the return shape or ordering, and it does not distinguish itself from get_following or explain the required acct parameter. The schema partially compensates, but the description alone leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 75% of the parameters with descriptions for limit, max_id, and account. The tool description adds no parameter-specific meaning beyond the schema. The required acct parameter remains undocumented in both description and schema, but the high schema coverage keeps this at baseline.
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: accounts that follow a given account. The title adds 'List', making the operation unambiguous. It is implicitly distinguishable from get_following (which lists accounts a given account follows), but it does not explicitly name the sibling or use a strong verb like 'returns' or 'lists'.
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 gives no guidance on when to use this tool versus siblings like get_following, get_account, or get_relationships. It provides no when-to-use, when-not-to-use, or alternative routing.
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?
It adds valuable behavior beyond the destructiveHint annotation: atomic pre-validation, immediate publication, and the need for confirm:true. However, it also makes inaccurate claims, referencing a 'poll' parameter absent from the schema and stating the content warning applies to the first part when the schema says it applies to every part.
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 tight and front-loaded: purpose first, atomicity second, and placement/confirmation third. The only structural flaw is the inaccurate poll and content-warning clause, which undermines an otherwise economical definition.
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?
It covers the most critical operational facts: all parts are validated upfront, nothing publishes halfway, and confirm is required. Yet it lacks explicit guidance favoring post_status for single posts and contains a factual mismatch about poll and content-warning behavior, leaving noticeable gaps for a complex, irreversible mutation.
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 coverage is high, but the description adds incorrect parameter-level information: it mentions a poll that does not exist in the schema and contradicts the spoiler_text semantics. It provides no correct parameter detail beyond what the schema already documents.
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 and resource: 'Publish several statuses as one thread, each replying to the last.' This makes the tool's function unambiguous and distinguishes it from single-status posting via post_status.
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 this tool is for multi-status threads, but it never explicitly says when to choose it over post_status or when not to use it. Usage context is clear only by inference from the name and phrasing, not from explicit alternatives 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 mark readOnlyHint=false, consistent with a mutation, and the description adds a behavioral prerequisite (follow requirement) that likely causes an error if violated. This goes beyond the annotations, but it does not disclose behavior for duplicates, idempotency, or partial failures. It enriches moderately but remains limited.
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?
Two short sentences with no filler. The first sentence restates the title, while the second adds the valuable prerequisite/error insight. Efficient enough to earn a 4, though the opening sentence is mildly redundant with the title.
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 mutation with full parameter coverage, the description includes the key prerequisite an agent needs to avoid the common error. It does not address success/failure shapes or permission restrictions, but given no output schema and low complexity, this is an adequate level of 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond the follow prerequisite; it does not clarify formats for the 'account' selector or 'accts' values, but the schema already covers those.
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 clear verb and object: 'Add accounts to a list.' This unambiguously identifies the operation and distinguishes it from siblings like remove_from_list, create_list, or list_accounts. The title and description align without ambiguity.
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 one useful usage constraint: you must already follow an account before adding it to a list. However, it does not explicitly compare against alternatives or state when not to use this tool. The guidance is implied by the operation name rather than spelled out.
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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the useful locked-account context, but does not disclose details like return shape or edge cases. With annotations carrying most of the behavioral burden, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence defines the output concept, and the second adds an important scope restriction. 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 read-only list operation with fully documented optional parameters, the description is mostly complete: it conveys what is returned and the locked-account condition. A minor gap is not pointing to the related approve action, but the schema and annotations cover the rest.
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 limit, max_id, and account each have clear descriptions. The tool description contributes no additional parameter-level meaning, so the baseline of 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 title 'List pending follow requests' and description 'Accounts waiting for you to approve their follow' clearly identify the resource and the action. It implicitly distinguishes itself from get_followers and answer_follow_request by focusing on pending approval, though it does not explicitly contrast a sibling tool.
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 one useful condition: 'Only meaningful on a locked account,' which is a clear prerequisite. However, it does not explain when to use this tool instead of related tools like answer_follow_request or get_followers, leaving alternatives to inference.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is carried by structured data. The description adds the 'not published yet' scoping, which is useful, but it discloses nothing about ordering, pagination, or how in-flight/failed scheduled posts are treated.
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 with no filler; every word carries meaning. The filtering condition is front-loaded and precisely phrased.
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 list tool with one optional, well-documented parameter and annotations covering safety, the description is sufficient. The return shape (a list of statuses) is implied by the name and description; only minor details like ordering are absent, which does not impede correct invocation.
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%: the account parameter is fully documented in the schema (matching rules, default behavior, pointer to list_accounts). The description adds nothing about parameters, but the baseline of 3 applies because the schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Statuses queued with scheduled_at that have not published yet' uses a clear verb-scope pair and pins down the resource (statuses) with a precise filter (queued, not yet published). It distinguishes itself from write-oriented siblings like reschedule_status and cancel_scheduled_status, though it does not name any sibling explicitly.
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 filtering condition implies when to use it — when you need to see pending scheduled posts — but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as reschedule_status, cancel_scheduled_status, or get_status. Usage must be inferred rather than stated.
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 non-read-only, non-destructive, idempotent behavior. The description adds valuable behavioral context about the lasting effect on severed follows, which is beyond what annotations provide. It does not mention authentication or permission needs, but the key side effect is disclosed.
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, both earning their place: the first gives the core action, the second highlights a crucial side effect. No unnecessary words or restatements.
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 mutation tool with annotations, the description covers the core action and a side effect. However, it lacks usage context, does not explain the required parameter, and offers no examples or mention of expected outcomes. It is adequate but leaves some gaps.
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 coverage is only 50%, with the required 'acct' parameter lacking any description. The description does not clarify what 'acct' should represent, and while the 'account' parameter has schema documentation, the description adds no further meaning. The description fails to compensate for the undocumented required parameter.
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?
Description states the specific verb 'Remove' and resource 'a block', making it clear this unblocks an account. It clearly distinguishes itself from related siblings like block_account, and the added sentence about severed follows provides meaningful context.
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 on when to use this tool versus alternatives such as block_account or unblock_domain. There is no mention of prerequisites, intended workflow, or conditions under which unblocking should be performed.
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 read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: only opted-in accounts are visible, ordering is by new or recently active, and instance scoping is the default. This is useful for setting agent expectations, though it does not mention pagination or output shape.
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?
Three short sentences with the most important scoping and ordering information front-loaded. The final sentence about finding people without a recommendation engine adds context without bloating the description.
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 browsing tool with four optional parameters, all schema-documented, the description covers the key decision factors: who is included, ordering, and scope. It does not detail the result shape, but the concept of browsing a directory of accounts makes the expected output reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the order and local-only semantics, but it does not add new parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says this tool lists accounts that opted into discoverability, sorted by newest or most recently active, and scoped to an instance. That is a clear resource and behavior, though the verb 'browse' is only in the title and it does not explicitly distinguish itself from sibling search or follow-suggestion tools.
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?
It gives situational color: scoped to your own instance unless you ask for the wider network, and positioned as a way to find people without a recommendation engine. However, it never says when to prefer it over alternatives like search or get_suggested_follows, and it offers no explicit when-not-to-use 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description only needs to add context beyond them. It does exactly that by disclosing that locked accounts trigger a follow request instead of a direct follow, which is a meaningful behavioral edge case not otherwise expressed in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence states the core action plainly, and the second front-loads an important edge case. Minor redundancy with the title exists, but nothing wasteful.
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 mutating tool, the description plus the rich schema parameter descriptions and annotations cover the main behavior and the key locked-account edge case. There is no output schema and no return-value detail, but that is a minor gap for a follow action and does not prevent correct invocation.
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 parameter descriptions already explain acct formats, notify semantics, account selection, and the reblogs default. The tool description adds no parameter-specific detail, so the baseline 3 applies.
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 and resource ('Follow an account') and adds an important conditional: locked accounts receive a follow request instead. The noun 'account' clearly separates it from sibling tools like follow_hashtag and from account-modifying tools such as block_account or mute_account.
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?
There is no explicit when-to-use guidance, exclusion criteria, or mention of alternative tools such as follow_hashtag or answer_follow_request. The locked-account note describes behavior, not selection context, so the agent must infer usage purely from the tool name and title.
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 the safety profile: read-only, idempotent, non-destructive, open-world. The description adds useful context about the content domain and the actionable meaning of mention, but it does not describe pagination, ordering, or response structure. There is no contradiction with 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?
Two tight sentences: the first defines scope, the second gives high-value selection guidance. Nothing is wasted, and the actionable filtering tip is front-loaded for practical use.
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 a well-described schema and strong annotations, the description is sufficiently complete: it states what notifications are included and how to filter. It could mention admin notification types or response ordering, but the schema's enum and pagination fields compensate.
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 input schema already documents all six parameters at 100% coverage, so the baseline is 3. The description adds value by framing the types parameter as a way to isolate notifications needing answers and by explaining that 'mention' is the actionable case, which helps the agent choose parameter values intentionally.
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 enumerates the notification kinds returned—mentions, boosts, favourites, follows, poll results, and edits—making the resource clear without being a pure tautology. Combined with the title 'Read notifications,' an agent can tell this is a read/list operation, though it doesn't explicitly state a verb like 'list' or 'fetch.'
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 practical usage guidance: filter by type to get only actionable notifications, and specifically treat 'mention' as the item a human must deal with. It does not explicitly compare against siblings like dismiss_notification, clear_notifications, or get_read_position, so the agent has to infer when this read tool is preferred.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that each suggestion includes a reason, which is useful context, but it does not disclose behaviors like pagination, ordering, or how suggestions are generated.
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 with no filler, front-loaded with the resource and augmented by one key detail (reason per suggestion). Every word earns its place.
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 read-only tool with two optional parameters and comprehensive annotations, the description conveys the essential return content (accounts and reasons). No output schema exists, but the description sufficiently indicates what the agent will receive, and the account parameter description is thorough.
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 detailed descriptions for both limit and account parameters. The description itself adds no parameter-level meaning, so the 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 identifies the resource ('Accounts the instance suggests you follow') and adds a distinguishing detail ('with the reason for each suggestion'). This separates it from sibling tools like get_followers and get_following, which return explicit relationship data.
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 gives no explicit guidance on when to use this tool versus alternatives such as get_follow_requests, get_followers, or get_following. An agent must infer usage solely from the tool name and description, with no contrast to related follow-related operations.
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 declare this is a non-readonly, non-destructive, non-idempotent operation. The description adds meaningful behavioral context beyond those annotations by clarifying that removing from a list does not unfollow the account. This prevents a natural misunderstanding, though it does not discuss error cases or effects on previously removed accounts.
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 short sentences with no filler. The primary action is stated first, and the key caveat follows immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters that are not described in the schema or description, an agent may struggle to invoke it correctly. The high-level purpose is clear, but details about what 'id' refers to and what format 'accts' entries take are missing. With no output schema, the description does not fully compensate for these gaps.
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%, with only the optional 'account' parameter described. The two required parameters, 'id' and 'accts', are undocumented in both the schema and the description. The description provides no additional meaning for these parameters, leaving their semantics ambiguous (e.g., what accts entries should contain).
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 action, removing accounts from a list, and immediately adds a crucial distinguishing detail: 'They are not unfollowed.' This clearly differentiates it from unfollow_account and other list/unlist operations. The verb and resource are explicit and match the title.
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 sentence 'They are not unfollowed' implies a use case and warns against confusing this tool with unfollow actions, but it does not explicitly name alternatives or state when to prefer this tool over add_to_list or unfollow_account. Usage context is implied rather than made 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds useful domain context about what announcements contain but does not disclose additional behavioral traits such as pagination, ordering, or handling of already-dismissed announcements beyond what the schema parameter hints.
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 short sentences, both earning their place: the first defines the resource, the second gives the practical trigger for use. No filler or redundancy, and the most essential 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 read-only tool with zero required parameters, a well-documented schema, and safety annotations, the description covers intent and appropriate use. It does not describe the return shape or pagination, but given the low complexity and lack of required inputs, the available context is sufficient for an agent to invoke it 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?
Schema description coverage is 100%, so both parameters (account and include_read) are already documented in the schema. The tool description adds no parameter-specific meaning beyond that, so the baseline score of 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 ('Announcements from the people who run your instance') and the concrete content types (downtime, rule changes, moderation decisions). It is specific about the verb-resource pairing, though it does not explicitly contrast with sibling tools like get_instance_info.
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 'Worth checking when something stops working' gives a clear, concrete trigger for when an agent should call this tool. It does not mention exclusions or name alternatives, but the usage context is more specific than the bare verb-plus-resource pattern seen in many sibling definitions.
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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations: it reveals the privacy model ('anyone mentioned in one can see it') and the ordering behavior ('newest first'). This helps an agent understand side effects and visibility semantics.
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 first sentence is front-loaded with the core behavior, and the second explains a key Mastodon-specific nuance. The third sentence about existing MCP servers is not directly actionable for invoking the tool, but it is brief and does not significantly bloat the description. Overall it is tight and well ordered.
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?
With no output schema, the description reasonably summarizes the return shape ('participants and last message') but leaves out response envelope, pagination behavior, and exact field structure. The two parameters are fully described in the schema, so the main gap is response detail. This is adequate but not fully 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%, so both 'limit' and 'account' are already well documented by the input schema. The tool description adds no additional parameter-level explanation, which is acceptable given the schema's completeness. Baseline 3 is appropriate here.
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 names a specific resource ('Direct conversations') and states exactly what is returned: 'newest first, each with its participants and last message.' It also clarifies that Mastodon direct messages are statuses with visibility 'direct', which helps distinguish this from standard timeline tools. This is a clear, actionable 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about how Mastodon models direct messages, implying when this tool is relevant. However, it does not explicitly say when to prefer this over alternatives like get_home_timeline or mute_conversation, and it offers no exclusionary guidance. The usage intent is clear but largely inferred.
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 'Pages automatically,' a useful behavioral detail beyond the annotations' readOnly/openWorld/idempotent hints. It does not contradict annotations, and for a simple read-only listing tool the pagination note provides meaningful 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?
Two short sentences with no filler; the core behavior is stated first and the pagination behavior follows. The description is efficiently sized for a simple list tool.
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 operation, the description, schema, and annotations together cover the essential behavior, parameters, and safety profile. The lack of an output schema is acceptable because the return type ('accounts') is implied.
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 75%: limit, max_id, and account already have descriptions. The phrase 'given account' clarifies that acct is the target account, but the description does not add format or default details beyond the schema. This meets the baseline for high schema coverage.
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 names the resource ('accounts a given account follows') and the title supplies the verb 'List', making the purpose clear. It is distinguishable from the sibling get_followers because it targets accounts the given account follows rather than followers.
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?
'Accounts a given account follows' implies the tool is for retrieving another account's follow list, but it gives no explicit guidance about when to prefer it over alternatives like get_followers or get_suggested_follows. 'Pages automatically' hints at handling paginated results but not when or how to request subsequent pages.
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 idempotentHint=true, covering the safety profile. The description adds valuable context by specifying 'Public statuses' (excluding non-public ones) and explaining that hashtags serve as the primary discovery mechanism, which goes beyond what annotations state and helps the agent understand the tool's role.
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 only two sentences, with the core action stated upfront and the contextual rationale following. Every sentence earns its place, no redundancy, and it's well-structured for quick parsing.
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 a rich schema and no output schema, the description adequately covers what the tool does and why it matters. It doesn't explain return formats or pagination details, but those are handled by the schema and annotations, so the description is sufficient for an agent to decide when to call it.
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 with descriptions for all 9 parameters, including filtering options (all, any, none), pagination (limit, max_id), and account selection. The description adds no additional parameter-specific meaning, so it relies entirely on the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns public statuses carrying a specific hashtag, with a concrete verb and resource. It distinguishes hashtag-based timelines from other timeline tools by its subject matter, but does not explicitly name sibling alternatives like get_home_timeline or get_local_timeline, so it stops short of a 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 implies usage for discovering conversations around a hashtag, noting it's 'the main way to find a conversation' on Mastodon. However, it provides no explicit when-to-use vs alternatives, no exclusions, and no mention of cases where other timeline tools would be more appropriate, leaving usage guidance mostly implicit.
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, idempotentHint, and destructiveHint, so the description only adds the scope that it returns statuses from accounts on the user's lists and where to obtain list IDs. This is useful context but not rich behavioral detail beyond what annotations and schema already convey.
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-loading the core purpose and immediately pointing to get_lists for the required list_id. No unnecessary words; each 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?
For a read-only timeline tool with full schema descriptions and annotations, the description is sufficient: it explains what it returns, where to find the required list_id, and the schema covers all parameters and pagination details. It lacks explicit authentication notes but that is implicit across the toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are documented in the schema. The tool description does not add any additional parameter semantics beyond the schema, matching 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 clearly states the resource (a list's timeline) and the action (retrieve statuses), and explicitly distinguishes it from other timeline tools by referencing 'one of your lists' and pointing to get_lists for list IDs. This separates it from siblings like get_home_timeline or get_local_timeline.
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 context by noting it's for lists you own and provides a prerequisite (find list IDs with get_lists), but it does not explicitly state when to use this tool versus alternatives like get_home_timeline or get_hashtag_timeline. The 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 this is a non-read-only, non-destructive, idempotent operation. The description adds the nuance that only the profile pin is removed, not the status itself, but provides no additional behavioral context such as side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It conveys the exact action and scope in minimal words, and the essential verb and resource are 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, idempotent action with a fully documented schema and safety-relevant annotations, this description is sufficient. Nothing critical is missing for an agent to invoke it correctly, though it does not describe the expected response format.
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 covers both parameters fully, including what 'id' refers to and how 'account' can be specified. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Unpin') and a specific resource ('a status from your profile'). It clearly distinguishes this from siblings like delete_status, pin_status, or unfavourite_status by limiting the action to profile pin removal.
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 the tool is used when wanting to remove a status from the profile's pinned list. However, it does not explicitly state when not to use it or mention alternatives like delete_status, leaving the contrast to inference.
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 safety (readOnlyHint, idempotentHint, destructiveHint false). The description adds behavioral context beyond those: content is public, scoped to the local instance, and can be a high-volume 'firehose' on large instances, which is useful for expecting large result sets.
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 only two sentences and front-loads the core definition. The second sentence adds useful usage context, though the subjective 'most useful timeline there is' is slightly less precise than a more objective condition would be.
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 timeline tool with robust annotations and fully documented parameters, the description plus input schema is sufficient. It establishes scope, content type, and scale. It doesn't explicitly describe the response shape, but the name and schema's pagination references make the return type reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a meaningful description. The tool description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the resource and scope: 'Everything public posted by accounts on your own instance.' This distinguishes it from the federated timeline (other instances) and the home timeline (followed accounts), while the tool name and title provide the read/get verb.
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 useful context ('On a small themed instance this is the most useful timeline there is; on mastodon.social it is a firehose') that implies when it is appropriate, but it does not explicitly name alternatives like get_federated_timeline or get_home_timeline 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 establish that the tool is a non-read-only, idempotent, non-destructive operation. The description adds behavioral context beyond the annotations by stating that muting does not require leaving the thread, which clarifies the key side effect an agent needs to know.
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 first sentence is a tight, front-loaded description of the tool's purpose. The second sentence is a stylistic aside that does not add operational value, so it is not flawless, but overall the description is still appropriately short.
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, idempotent mutation with no output schema, the description plus annotations cover what the tool does and its main side effect. It could explicitly point to unmute_conversation as the reversal, but nothing essential for invoking the tool correctly 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?
Schema description coverage is 100%, with both id and account already documented including how account matching works and the default. The description adds no additional parameter-level meaning, so it correctly sits at the schema-covered baseline of 3.
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 first sentence states a specific action and resource: stop being notified about replies to this thread without leaving it. This clearly scopes the tool to conversation-level muting and distinguishes it from account-level mute tools and the sibling unmute_conversation. The added flavor sentence does not obscure the purpose.
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 a use case with 'until a post goes unexpectedly wide' but provides no explicit guidance about when to choose this over alternatives like mute_account or how to reverse it with unmute_conversation. This is only implied usage context, not actionable when/when-not 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?
The description adds a meaningful behavioral detail beyond annotations: rejecting a request is silent and the requester is not told. This is useful, non-obvious context that annotations do not provide. The broader effects of approval are left implicit, but the annotations already establish the mutation profile.
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 only two sentences long, front-loads the core action, and adds one high-value behavioral caveat. Every word earns its place, with no vague filler or unnecessary repetition.
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-decision mutating tool, the description gives an agent enough context to select the tool and choose approve vs reject; the schema fills in the account selector and decision enum. Minor gaps include not describing the expected outcome/return shape and not pointing to get_follow_requests as the listing step.
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 tool description clarifies that decision values map to approve/reject and that 'acct' refers to the requesting account. However, 'acct' remains under-specified regarding expected format, and the description mostly restates the enum semantics rather than adding new parameter-level detail 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 names the exact action (approve/reject) and exact resource (pending follow request). It differentiates itself from sibling tools like get_follow_requests, which lists requests rather than acting on them, and follow_account, which initiates a follow rather than resolving a pending one.
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 clearly implies the appropriate context—acting on a pending follow request—but it does not explicitly state when this tool should be preferred over alternatives. It also does not suggest get_follow_requests as the companion tool for enumerating pending requests before calling this one.
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 this is a non-read-only, idempotent write, and the description adds the meaningful effect on the home timeline. It does not cover auth requirements or any side-effect caveats, but the annotation context lowers the burden on 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?
Two tight sentences, front-loaded with the action and its effect. There is no filler, no repetition of schema details, and 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?
For a simple mutation with one required parameter, complete schema descriptions, and rich annotations, the description is sufficient for an agent to invoke the tool correctly. It does not describe the response shape, but there is no output schema and that is not needed to decide to call it.
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?
Input schema coverage is 100%, and the schema already documents account resolution and that the hashtag may include a leading #. The description adds no parameter-level meaning beyond what the schema provides, so the baseline applies.
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?
States an explicit action and its consequence: following a hashtag routes every public post carrying it into the home timeline. It also positions the tool as 'the main way to build a feed on Mastodon,' distinguishing it from read-only alternatives like get_hashtag_timeline and from unfollow_hashtag.
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?
Gives a clear use case ('the main way to build a feed on Mastodon') plus a concrete behavioral effect, so an agent can tell when following a hashtag is the right operation. It does not explicitly discuss when to use a hashtag timeline or unfollow instead, but the context is unambiguous enough.
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, idempotentHint=true, and destructiveHint=false, so no extra safety disclosure is needed. The description adds useful behavioral context beyond the schema by specifying that media, poll, link preview, and engagement counts are included in the result, which is valuable since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the core purpose and key result contents with zero filler. Every word contributes value, and no unnecessary enumeration or repetition is present.
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 fetch with two parameters, one required, the description plus annotations cover the safety profile and the important returned components. The main gap is that it does not mention the optional account parameter or when to supply it, but the schema already provides that information, so the overall package is nearly 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 description adds mild meaning to the id parameter by saying the status is fetched 'by id,' but it does not describe the account parameter at all. The account parameter is well documented in the schema, so the description does not need to repeat it, yet with only 50% schema coverage for id 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 states a specific action — fetching a single status by ID — and distinguishes it from siblings like get_thread (surrounding context), get_status_source (source text), and get_status_history (edit history) by emphasizing a single status with its media, poll, link preview, and engagement counts. The title and resource are clear and not tautological.
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 'A single status by id' implies the tool is for fetching one known status, which gives some usage context. However, it does not explicitly say when to prefer this over get_thread, get_status_source, or get_status_history, nor does it mention any exclusions or alternatives. Usage 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 destructiveHint=true and non-read-only, and the description adds genuinely useful behavioral context: the status becomes public the moment it runs, the action needs explicit confirmation, and the character limit depends on the instance. It does not contradict the annotations and communicates the irreversible nature beyond what the flags convey.
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 compact and front-loaded, starting with the operation, then summarizing capabilities, then delivering the two most important caveats. The capability list partially mirrors the schema, but the critical warnings are prominent and there is no padding.
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 mutation tool with no output schema, the description covers the key selection and safety information: what it does, the high-stakes public/immediate behavior, the confirmation requirement, and a per-instance constraint. It could be stronger by explicitly routing to post_thread for multi-status scenarios, but the schema and annotations fill most remaining gaps.
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 92% schema description coverage the schema carries most parameter meaning, but the description adds real value for the `status` and `confirm` parameters: it warns to check get_instance_info for the per-instance character limit and explains why confirm:true is mandatory. That is more than the schema alone provides, though most other parameters still rely on 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 opens with 'Publish a status' and enumerates the supported capability set (text, media with alt text, content warning, poll, reply, visibility, scheduling), making the core operation unmistakable. It does not explicitly distinguish itself from sibling tools like post_thread or edit_status, which keeps it from a 5.
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 clear practical context: check get_instance_info before drafting long content because the character limit is per-instance, and confirm:true is required because the result is public and irreversible. It does not name alternatives or state when not to use this tool, so it falls short of explicit routing but is more than a bare prerequisite.
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 convey readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds the Mastodon quote-post limitation but does not explain how a boost appears or that it can be undone via unboost_status. This is adequate but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core action stated first and the caveat second. The first sentence repeats the title almost verbatim, which is mild redundancy, but the overall structure is tight and scannable.
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 one-required-parameter mutation with no output schema, the description plus schema and annotations cover the necessary call context. It addresses the main ambiguity (boost vs. comment), account selection is documented in the schema, and idempotency is annotated. Mentioning reversibility would improve completeness but is not essential.
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 account parameter already explains matching rules, defaults, and how to list accounts. The tool description contributes no additional parameter-level semantics, so the baseline score of 3 applies.
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 and resource ('Boost a status to your followers') and immediately distinguishes itself from adding a comment. This separates it from related sibling actions like favourite_status, post_status, and unboost_status.
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 tells the agent when not to use this tool: to add a comment instead, post a status quoting the URL because Mastodon has no native quote post. This is a clear when-not/alternative routing that prevents a common misuse.
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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is fully covered. The description adds that bookmarks are private, which is useful conceptual context but not a distinct behavioral characteristic such as pagination, ordering, or authentication requirements.
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 front-loads the core purpose and immediately adds the privacy distinction. Every word earns its place; no filler or redundant restatement of the title.
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 read-only list tool with two fully documented parameters and robust safety annotations, nothing an agent needs to call it correctly is missing. The privacy caveat closes the main conceptual gap versus favourites, and the schema handles all operational details.
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 params, limit and account, already have rich descriptions including defaults, bounds, matching rules, and fallback behavior. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline 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 states a clear verb-resource pair: 'Statuses a connected account has bookmarked.' It also distinguishes itself from the sibling get_favourites by noting bookmarks are private, which is the key differentiator among the similarly named tools.
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 — listing statuses bookmarked by a connected account — and explicitly contrasts with favourites. It does not name the sibling tool get_favourites directly, but the 'unlike favourites' comparison effectively routes the agent away from the most likely alternative.
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, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds useful behavioral context beyond this: results are ordered newest first and are scoped to a connected account.
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 conveys scope and ordering without any filler. The most relevant information is front-loaded and every word earns its place.
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 list tool with two optional parameters, complete annotation coverage, and no output schema, the description plus schema is sufficient. The return value is implied by 'statuses', ordering is stated, and selection behavior is covered by the 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%, so the parameters are already fully documented in the schema. The tool description adds no additional parameter-level meaning beyond the schema, matching the baseline for high 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 resource ('statuses') and a specific scope ('a connected account has favourited'), plus an ordering qualifier ('newest first'). It clearly distinguishes this from siblings like get_favourited_by (who favourited a status) and get_bookmarks (bookmarked statuses).
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 you need a connected account's favourited statuses. However, it offers no explicit when-not-to-use guidance or comparison with alternatives such as get_bookmarks or get_account_statuses.
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, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context by explaining that trends are per-instance and not network-wide, which is a key behavioral trait that affects what results to expect. It does not contradict 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?
Two sentences with no filler. The first sentence immediately states what the tool returns and its variants; the second sentence adds crucial scope information. Every word earns its place, and the most important info is front-loaded.
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 read-only listing tool, the description plus the fully documented schema and safety annotations cover everything an agent needs to invoke it correctly. The instance-scoped nature is disclosed, and all parameters are defined in the schema. No output schema exists, but return values for trend endpoints are generally self-evident.
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 already documents all parameters with 100% coverage. The description adds some meaning for the 'kind' parameter by enumerating the three values in prose, but does not add anything about 'limit' or 'account'. Baseline 3 is appropriate 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 states exactly what the tool does: returns current trends on this instance, listing the three kinds (hashtags, statuses, links). It clearly distinguishes itself from network-wide trends and from sibling timeline tools by emphasizing the per-instance scope.
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 about when to use this tool (when you need instance-specific trends) but does not explicitly state when not to use it or mention any alternative tools. The usage guidance is implied through the scope clarification rather than directly stated.
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 indicate destructiveHint=true, but the description adds substantial context: the block is visible to the target, removes follows in both directions, hides posts, is reversible while the follows do not return, and requires confirmation. This goes well beyond the structured metadata, fully disclosing side effects and reversibility.
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?
Four short, information-dense sentences with no filler. The core action is front-loaded, followed by the most important effects, then the confirmation caveat. Every sentence contributes distinct value.
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 explains the core behavior, side effects, reversibility, and confirmation requirement, which is sufficient for an agent to execute the tool. The only notable gap is the lack of detail on the 'acct' parameter format, and since there is no output schema, the description carries the burden of explaining what the call achieves—which it does well.
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% because the required 'acct' parameter has no description. The tool description does not clarify what format 'acct' should take, leaving that gap unaddressed. It does reinforce the meaning of 'confirm' via the 'Needs confirm: true' note, but does not add meaning for the undocumented parameter, so a baseline score applies.
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?
States a specific verb and resource ('Block an account') and goes beyond the title by enumerating exact consequences: visibility to the target, removal of follows in both directions, and hiding of posts. This differentiates the action from siblings like mute_account or block_domain by describing the precise behavioral effect.
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 the appropriate use case—when you want to block and hide your posts from an account—and clearly signals the confirmation requirement. However, it does not explicitly name alternatives like mute_account or unblock_account, nor does it state when NOT to use this tool, leaving selection partially to inference.
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 carry destructiveHint=true and readOnlyHint=false. The description adds concrete behavioral context beyond that: it hides entire instance accounts and removes followers, and it flags the confirmation requirement.
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 plus a short confirmation note. Every part earns its place: the action, the usage context, and the confirmation requirement.
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?
It communicates scope, purpose, and confirmation need, and the schema handles parameter details. It does not describe the return value or reversibility, but the destructive annotation and confirm flag make the operation adequately clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents domain, account, and confirm. The description only mentions confirm, adding no meaningful parameter 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 says exactly what the tool does: hide every account on an instance and remove their followers. It further distinguishes this from a single-account action with 'rather than one account', making it clear versus sibling tools like block_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?
It gives a clear usage condition: use this when a server is a persistent problem rather than one account. It does not explicitly name alternative tools or state when not to use it, so it is slightly below a 5.
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?
Given the annotations already declare non-read-only, non-destructive, and idempotent behavior, the description adds useful context about the visibility of bookmarks versus favourites. This goes beyond the structured annotations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and leads with the core action. The first sentence repeats the title, a minor redundancy, but the second sentence earns its place by adding differentiating context, so there is no meaningful bloat.
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 one-required-parameter action, the description plus schema fully equips an agent to invoke it: id and account are documented, the privacy behavior is stated, and annotations cover side-effect expectations. No output schema is present, and none is needed for correct invocation.
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%: id and account are both clearly documented in the input schema. The tool description adds no parameter-level meaning, so the baseline 3 applies.
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?
States a specific verb and resource ('Bookmark a status') and immediately distinguishes the action from favourites by noting bookmarks are private, which separates it from the sibling favourite_status tool. Even though the first sentence mirrors the title, the added privacy scope makes 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?
The privacy contrast ('unlike favourites, which the author can see') gives clear situational guidance: use bookmarks when the action should be private and favourites when author visibility is acceptable. It does not explicitly name the alternative tool, so it stops short of a full when/when-not statement.
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 destructiveHint=true and readOnlyHint=false, so the description's added value is the irreversibility ('no undo'), the permanent/delete-all scope, and the explicit confirmation requirement. These are useful behavioral details 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 short sentences with no filler: the action comes first, the key caveats follow, and the confirmation requirement is stated plainly. 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?
For a destructive action with two well-documented parameters and no output schema, the description covers what happens, how permanent it is, and what gate must be satisfied. It could be slightly more explicit about the selected account scope and name mark_read/dismiss_notification as alternatives, but the schema and sibling list cover most of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented. The description's 'Needs confirm: true' reinforces the confirm parameter but adds no meaning beyond what the schema already says about confirm, and it says nothing new about account.
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 specific, unambiguous action: 'Delete all notifications permanently.' It also distinguishes the operation from 'marking them read,' which clearly separates it from sibling tools like mark_read and dismiss_notification.
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: this is a permanent, confirm-gated delete-all operation, and it explicitly says it is not equivalent to marking notifications read. It does not name the alternative tool to use for read-only marking, but the exclusion is enough for an agent to avoid the most likely confusion.
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 discloses meaningful behavioral context beyond the annotations: Mastodon keeps a public revision history, the post retains boosts/replies/favourites, and the edit is public the moment it runs so confirm is required. This complements the destructiveHint and readOnlyHint annotations 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?
Four concise, front-loaded sentences deliver the action, rationale, prerequisite, and safety requirement with no filler. Every sentence earns its place in the description.
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 mutation with 8 parameters and no output schema, the description covers the core workflow, prerequisite, and public-feedback consequence. It does not describe return values or rate limits, but those are not essential for this tool given the schema's parameter coverage.
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 75%, so the schema already documents most parameters. The description adds little parameter-specific meaning beyond mentioning the editable fields and the confirm requirement; it does not compensate for the undocumented language and sensitive 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 opens with a specific verb and resource ('Change the text, content warning, media alt text or poll of a status that is already published'), which unambiguously identifies the operation. It also distinguishes editing from delete-and-repost, making the tool's purpose clear even among many sibling tools.
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 frames when this tool is appropriate ('editing beats delete-and-repost') and gives a concrete prerequisite ('Call get_status_source first to get the exact text you are editing'). It does not explicitly enumerate when not to use it, so it stops short of fully explicit exclusion 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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the range of possible character limits and the nature of the data returned, which is beyond the annotations. It does not contradict 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 two sentences, front-loaded with the key purpose, and includes a practical tip. Every sentence earns its place without extraneous 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?
The tool is simple (one optional parameter) with rich annotations covering safety and idempotency. The description explains what data will be returned, fulfilling the agent's need to know what to expect. No output schema exists, but the description sufficiently enumerates the content. A minor gap is the lack of a note about account selection behavior, but the schema addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the account parameter is fully documented in the schema. The description does not add parameter-specific details, but since the schema covers it, a 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 reads the instance's rules and limits, enumerates specific data points (character limit, attachments, poll options, media size, software version, server rules), and distinguishes it from siblings by its focus on instance configuration rather than timelines or statuses.
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 advises reading it before drafting anything long, given the variable character limit. While it doesn't name alternative tools, it provides clear usage context that an agent can act on. No exclusion criteria are stated, but the use case is specific enough.
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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds valuable behavioral detail: it specifies the order (oldest first) and that all published versions are returned, which is not captured by 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 concise and front-loaded, with two sentences that state the core behavior and a key insight about public accessibility. Every word adds value, with no filler 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 read-only tool with annotations covering safety, the description provides enough detail for an agent to call it correctly: it explains the output order and the public nature. It does not describe the exact return format, but the absence of an output schema and the simplicity of the operation make this 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 input schema describes the 'account' parameter but leaves 'id' undocumented, giving 50% schema coverage. The description does not mention parameters directly, but the tool's name and context make it clear 'id' is a status ID. The description adds minimal value beyond the schema, so a baseline 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 identifies the tool's purpose: retrieving the edit history of a status, ordered oldest first. It distinguishes itself from sibling tools like get_status and get_status_source by focusing specifically on the history of published versions, and the mention that it works for any public post adds scope.
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 stating that edits are public and the tool works for anyone's post, not just the user's own. This implies appropriate usage for retrieving public edit histories, though it does not explicitly name alternatives or state when not to use the tool.
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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations by explaining that Mastodon returns two flat lists and this tool rebuilds the nested tree, clarifying why this tool exists. No contradiction with 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, front-loaded with the result, then the rationale. Every sentence earns its place; 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 operation with annotations covering safety, the description adequately explains the returned structure (the nested tree) and the purpose. It lacks pagination or error handling details, but those are not essential for correct invocation given 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?
Schema coverage is 100%, with both id and account fully described in the input schema. The description adds no additional semantic meaning beyond what the schema provides, so the baseline 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 states a specific verb+resource ('A status together with everything above and below it, nested into the real reply tree') and clearly distinguishes it from siblings like get_status (single status) and get_conversations (list of conversations). It also adds a concrete use case ('Read this before replying'), 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?
The description gives explicit contextual guidance: 'Read this before replying, so the reply lands with context.' This tells the agent when to use the tool. However, it does not name alternative tools or explicitly state when not to use it, leaving some ambiguity for agents comparing it with get_status or get_conversations.
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 idempotentHint=true and destructiveHint=false, and the description adds meaningful context: 'Private and reversible' and the fact that the muted account can still interact. This goes beyond the structured fields and informs the agent about side effects (or lack thereof). It doesn't mention edge cases like repeated muting or effects on notifications, but given the annotations cover safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The core purpose ('hide an account from your timelines') is front-loaded, followed by a compact, high-value clarification about privacy and the block contrast. 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 simple mutation tool with no output schema and strong annotations, the description covers the essential behavioral contract: what it does, its reversibility, and how it differs from a block. Minor gaps include what happens if the account is already muted or if the duration expires, but those are not critical for correct invocation. The description is sufficiently complete for an agent to decide and call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (acct, account, duration) with descriptions. The tool description adds no extra meaning about parameters or their relationships, so the baseline of 3 for high coverage 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?
States a specific verb ('hide'), a resource ('an account'), and the effect ('from your timelines') with the crucial nuance that it's private and reversible. It explicitly contrasts with a block, distinguishing it from sibling tools like block_account, 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 contrasts with a block ('unlike a block, they can still see and reply to you'), which clearly implies when to choose mute over block. However, it doesn't explicitly state when not to use it (e.g., 'if you want to prevent them from seeing your posts, use block'), nor does it mention alternatives like unmute. The contrast is strong enough to infer usage, but lacks explicit exclusion.
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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by warning that most instances do not full-text search public statuses and that a thin result set is likely instance policy, not a bad query. It also explains the remote-resolution behavior, which is non-obvious and helpful.
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 with no filler. The first sentence states the core purpose, the second covers the special remote-resolve use case, and the third provides a critical interpretation warning. Information is front-loaded and 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?
For a read-only search tool with a rich input schema, the description covers the key behavioral nuance and the remote-resolution workflow. There is no output schema, and the description does not describe the result structure, but the missing return-value details are less critical for a search tool whose inputs are already fully documented. It is nearly complete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the input schema. The description reinforces the meaning of q and resolve with the URL-pasting example, but this is largely restating schema information rather than adding net-new parameter semantics. Baseline 3 is appropriate because the schema carries the load.
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 specific verb and resource: 'Search for accounts, statuses or hashtags.' It clearly distinguishes this broad search tool from more specific sibling tools like get_account, get_hashtag_timeline, or get_status by framing it as a general query-based search. The additional mention of resolving remote URLs further clarifies a unique purpose.
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 says when to use this tool: to paste a URL and pull in a remote post or profile the instance has never seen, with resolve on. It also provides a useful normative note about interpreting thin result sets. However, it does not explicitly contrast this with sibling tools or state when not to use it, so it falls just short of full 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?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds value beyond those hints by disclosing the dependency on instance configuration and explaining a non-obvious failure mode (404 means the feature is off). This is useful behavioral context that cannot be inferred from the schema or 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 two sentences with no wasted words: the first states the core action and mechanism, and the second delivers the critical 404 caveat. It is front-loaded and 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?
For a simple read-only translation call with one required parameter and well-described optional parameters, the description covers prerequisites, failure semantics, and instance-dependent behavior. The lack of an output schema means the return shape is left implicit, but an agent has enough information to 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?
Schema descriptions already document `lang` and `account` with defaults and matching behavior. `id` lacks a schema description, but the phrase 'a status' makes clear that `id` refers to the status being translated. The prose does not add meaningful parameter-level detail beyond what the schema provides, so it stays at baseline.
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 names the exact operation ('Translate a status'), identifies the mechanism (the instance's translation backend), and clarifies the scope ('into your language'). It sets the tool apart from the sibling list because no other sibling offers translation, and the 404 caveat makes its behavior distinctive.
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 actionable usage context: the tool only works on instances that have configured a translation backend, and a 404 should be interpreted as feature-disabled rather than status-missing. It does not name explicit alternatives, but no direct alternative exists among the siblings, so the guidance is adequate.
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 destructiveHint=true and readOnlyHint=false. The description adds useful side-effect context beyond that: accounts on the list are not affected. It also states the confirm requirement, reinforcing that this is a destructive action requiring explicit confirmation.
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 short sentences, each earning its place: the action, the side-effect scope, and the confirmation requirement. No filler or redundant elaboration.
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 operation, the description plus rich schema and annotations cover everything needed to call it correctly: what is deleted, what is not affected, and that confirm must be true. The absence of an output schema is not a meaningful gap for agent invocation here.
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 documents account and confirm thoroughly, and the tool description mentions 'Needs confirm: true.' The id parameter is not described in the schema, but its meaning as the list identifier is obvious from the tool name and description. Schema coverage is 67%, so this modest description meets the baseline without adding much new parameter detail.
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 and resource ('Delete a list') and immediately clarifies scope: 'The accounts on it are not affected, only the list.' This distinguishes it clearly from sibling tools like remove_from_list, which remove an account from a list rather than deleting the list itself.
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 this tool applies: deleting an entire list while leaving its member accounts untouched. It does not explicitly name alternatives or say 'use remove_from_list instead', but the exclusion of account effects makes the intended usage clear enough.
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 read-only, idempotent, and non-destructive behavior. The description adds useful behavioral details beyond that: newest-first ordering, the feed scope, and the since_hours time-window mode versus fixed-count mode.
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 lead with the core purpose and then add the one non-obvious usage nuance. There is 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 read-only timeline retrieval tool, the description plus fully covered schema provides all needed semantics: feed scope, ordering, pagination parameters, account selection, and the special time-window behavior. No output schema is needed because the return type is implied by 'statuses'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents limit, max_id, account, and since_hours. The description adds only a slight rephrasing of since_hours as a time-window alternative, providing minimal extra value.
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 operation and resource: reading statuses from accounts and hashtags you follow, ordered newest first. This clearly distinguishes the home timeline from siblings like get_local_timeline, get_federated_timeline, and get_hashtag_timeline.
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 'accounts and hashtags you follow' gives clear context that this is the personalized home feed rather than public or list-based timelines. However, it does not 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations: the read position is shared across every client on the account, and the returned id is a meaningful opaque token for incremental fetching. This enriches understanding without contradicting the hints.
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 with no wasted words. The first sentence defines the resource and its scope, the second gives actionable guidance on using the result. Information is front-loaded and every sentence earns its place.
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 read-only tool with one optional parameter and rich annotations, the description is complete. It explains what the return value represents, how it behaves across clients, and how to use it in downstream calls. There is no output schema, but the description sufficiently conveys the value's purpose. Missing edge cases (e.g., no read position yet) are minor given 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 single parameter 'account' has full description coverage in the schema (100%), including its matching behavior and default. The description itself adds no parameter-specific details, but the baseline of 3 applies because the schema fully documents the parameter.
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 a specific verb ('check how far you have read' from the title) and resource ('last notification and home-timeline entry you marked read'), and explicitly distinguishes its output's purpose ('Pass the returned id as since_id'). This differentiates it from siblings like mark_read or get_home_timeline.
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 instructions on how to use the returned value ('Pass the returned id as since_id to fetch only what is new'), giving clear practical guidance. However, it does not explicitly state when to use this versus alternatives (e.g., mark_read for setting the position), though the usage is strongly 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?
The description adds a meaningful behavioral consequence beyond annotations: 'Followers removed by the block are not restored.' Since annotations already convey non-read-only and idempotent behavior, this additional side effect is valuable and sufficient for this low-complexity 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 short sentences with no filler: the first states the primary action, the second states the most important side effect. Every word earns its place.
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 only two parameters, no output schema, and annotations that already cover mutation and idempotence, the description is complete. It tells the agent what happens and the key non-obvious consequence, leaving no critical call-time information 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 account parameter is well documented in the schema. The required domain parameter has no schema description, but the description's 'Lift a domain block' and the title 'Unblock an instance' make its meaning clear. Still, the description does not add explicit parameter-level details about what format `domain` should take, so it is adequate but not exceptional.
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 ('Lift') and resource ('domain block'), making the action unambiguous. The title and sibling tool block_domain reinforce that this is the inverse operation, so there is no confusion with account-level tools.
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 when to use the tool: when a domain block should be removed. It does not explicitly name block_domain as the alternative or provide when-not-to-use conditions, but the context is clear enough for an agent to route correctly.
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 discloses that a vote cannot be changed or taken back, requires confirm: true, and implies public visibility, all beyond what annotations alone convey. Annotations mark destructiveHint=true and readOnlyHint=false, which align with the irreversible write behavior; no contradiction exists.
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 core action and the most critical constraints (zero-based indexing, irreversibility, confirm requirement) are front-loaded and directly actionable.
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 fully documented parameters, the description covers all non-obvious call requirements: zero-based indexes, the required confirm flag, and irreversibility. No output schema exists, and the description does not need to explain return values for this simple vote action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already well-documented. The description adds little beyond reinforcing zero-based indexing and the confirm requirement; it provides context but not substantial new parameter-level detail.
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 ('Vote'), a clear resource ('a poll'), and the exact method ('by option index, counting from zero'). It unambiguously distinguishes vote_poll from all sibling tools, none of which target poll voting.
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 makes the intended action obvious and stresses the mandatory confirm flag, which is essential for correct usage. It does not list explicit alternatives or exclusions, but there is no sibling poll-voting tool, so no alternative routing is needed.
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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful context by noting the result is the 'live' profile and that the tool verifies token validity, which goes beyond the schema and 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?
Two sentences deliver the core purpose and primary use cases with no redundancy. The action is front-loaded and every phrase contributes useful 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?
For a simple, read-only, zero-required-parameter tool with strong annotations and full schema coverage, the description covers what the tool does, when to use it, and how it behaves. No critical information is missing for an agent to select and invoke it 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 schema provides 100% coverage of the single optional 'account' parameter with a detailed description. The tool description does not add parameter-specific meaning, but with full schema coverage the baseline 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 states a specific action ('Authenticate against the instance') and a clear output ('return the live profile'). It differentiates from sibling list_accounts by focusing on the current authenticated identity rather than enumerating connected accounts.
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 explicit conditions for use: confirming a token still works and resolving user references like 'me' or 'my'. It does not explicitly mention when not to use it or contrast with alternatives, but the stated triggers are concrete and actionable.
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 idempotentHint, so the safety profile is covered. The description adds meaningful behavioral detail: it is a batch call and reports reciprocal mute/block state, which the schema and annotations do not convey.
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 with distinct jobs: the first defines the output semantics, the second gives usage context. There is no redundant restatement of the title or schema.
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?
Even without an output schema, the first sentence tells the caller what relationship data will be returned. The description plus annotations and schema cover the necessary safety, batching, and parameter context, though it does not spell out the exact response field names.
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 the optional 'account' parameter well, and the description supplies the missing semantics for the required 'accts' parameter by referring to 'each account named' and 'a whole list.' It does not fully formalize the items, but the combination is adequate.
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 operation: for each named account, it checks follow status in both directions and mutual mute/block status. This distinguishes it from siblings like get_account and get_followers by emphasizing batch relationship checks.
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 says to use this before a bulk follow or unfollow and contrasts it with the slower per-profile approach. It does not name a specific sibling for single-account use, but the guidance is concrete enough for an agent to select it appropriately.
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 readOnly/idempotent annotations, it discloses that the output is raw typed text plus the content warning, and explains the pitfall of editing HTML-rendered content with rewritten links. It also adds an access constraint by limiting the source to the user's own statuses.
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 with no wasted words. The core definition is front-loaded and the second sentence earns its place by explaining why this tool is the correct source for edits.
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 read-only tool, the description plus annotations cover safety, the access restriction, the return content, and the most important behavioral pitfall. Nothing an agent needs to invoke it correctly is missing.
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 schema documents 'account' but leaves 'id' bare, and the description never explicitly maps 'id' to a status identifier. With schema description coverage at 50%, the description fails to compensate for the undocumented required parameter.
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 resource ('one of your own statuses'), the exact representation ('plain-text source... exactly as it was typed'), and the extra content ('plus its content warning'). The contrast with rendered HTML clearly marks it as distinct from content-returning siblings like get_status.
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 line 'This is what to edit from' gives clear use context, and the warning about link rewriting in rendered content implicitly explains why the rendered version is unsuitable. However, it does not explicitly name alternatives or state hard when-not-to-use conditions.
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 adds meaningful behavioral context beyond annotations: it syncs across clients and affects only the user's own view. It also explains the downstream effect on get_notifications with since_id. No contradiction with 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 tightly written sentences, with the core purpose front-loaded and supporting behavior in the following sentences. 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, optional-parameter mutation tool with no required fields and no output schema, the description covers purpose, effect, sync behavior, and scope. It does not clarify behavior when called with no parameters, but this is a minor gap given the overall clarity.
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%, so each parameter is already documented. The description adds some relational meaning by connecting the read position to get_notifications with since_id, but it does not substantially add parameter-level detail 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 uses a specific verb and resource: 'Record how far you have read' and names the effect on get_notifications with since_id. It clearly distinguishes this from siblings like dismiss_notification or clear_notifications by stating it affects only your own view.
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 clear context: use this to record read position so subsequent get_notifications calls return only new items. It does not explicitly list exclusions or alternatives, but the usage scenario is concrete enough for an agent to decide when to invoke 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 signal a mutating, non-destructive operation. The description adds the meaningful constraint 'Minimum five minutes ahead,' which is a behavioral trait not captured by annotations or schema. No contradiction with 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 two short sentences with no filler. The core action is front-loaded, and the key constraint is stated in minimal 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 mutation tool with three parameters and no output schema, the description plus annotations and schema cover the essentials: what to change, what identifies the target, and a key validation rule. It could mention the response or error cases, but those are not critical for invocation.
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 67%, and the description adds important meaning to scheduled_at by imposing a minimum-five-minutes-ahead constraint beyond 'New ISO 8601 time.' The purpose also clarifies that id refers to a scheduled status, compensating for its bare schema entry.
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 ('Change') and resource ('when a scheduled status will publish'), making the tool's function immediately clear. It naturally distinguishes this from siblings like cancel_scheduled_status or list_scheduled_statuses.
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 'Change when a scheduled status will publish' provides clear context for when to use this tool. It does not explicitly contrast it with cancel_scheduled_status or define exclusions, but the intended use case is evident.
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 adds significant behavioral context beyond the annotations: it discloses that the change is public immediately and that confirm:true is required. This complements the destructiveHint and openWorldHint annotations without 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?
Two tightly written sentences deliver the core purpose and a critical behavioral warning with no filler. Information is front-loaded: first sentence says what it does, second sentence says the key side effect and requirement.
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 plus the fully detailed schema provide enough for an agent to call the tool correctly. It lacks explicit error or confirmation-flow details, but the schema and annotations cover the safety profile and parameter meanings, making the definition complete for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description only mentions display name, bio, and metadata fields, which maps to some parameters but adds no semantics beyond the schema. 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 states a clear verb ('Change') with a specific resource ('your profile') and enumerates the key editable aspects (display name, bio, metadata fields). It also clarifies the partial-update behavior, so there is no ambiguity about 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 important usage context: only passed arguments are changed, and the action is public immediately, requiring confirm:true. It does not explicitly name alternatives, but there are no sibling tools for profile editing, so the guidance is appropriate.
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 it read-only, open-world, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it is large and unfiltered, which warns the agent about potential volume and noise. It does not describe ordering or pagination details, but those are partially covered by the parameter descriptions.
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 short sentences, zero filler, with the core resource definition first and practical usage direction second. Every sentence earns its place.
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 read-only timeline tool, the combination of the description, full parameter documentation, and safety annotations is complete. The description conveys the semantic scope and noise level, and the schema covers filtering, pagination, and account selection, so an agent has everything needed to invoke it 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?
Schema coverage is 100%, and each of the six optional parameters has a rich description covering defaults, pagination, account matching, and filters. The tool description itself adds no parameter-level detail, so a baseline 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 states a specific verb/resource: reading the federated timeline, defined as public content federated from the rest of the network. It also implicitly contrasts with local/home timelines and explicitly differentiates from search and hashtag timelines, so an agent can distinguish it from the many sibling timeline tools.
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 gives explicit when-to-use guidance: use it for broad, unfiltered public content, and use search or a hashtag timeline when looking for something specific. This names concrete alternatives and provides the decision condition.
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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: an account is a token plus an instance, and the same handle on two servers refers to two different people. It doesn't describe response shape or pagination, but for a zero-parameter read-only list 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?
Three sentences, each earning its place: the first states the result, the second explains the federated account concept, and the third tells the agent how to consume the output. The most important scoping phrase is front-loaded.
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, read-only list tool with annotations covering safety and no output schema, the description is complete: it explains what is returned, why the instance distinction matters, and how to use the result in other tools. Nothing essential 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?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, this score is appropriate; the description instead focuses on what will be returned.
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 names a specific verb and resource: it lists every Mastodon account the server can act as and the instance each account lives on. It also distinguishes this from a simple identity lookup by clarifying federated accounts, so an agent can tell it apart from tools like whoami or get_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 downstream context by telling the agent to use the handle from this tool as the account argument on any other tool. It doesn't explicitly name alternatives or state when not to use this tool, but the usage context is unambiguous for a zero-parameter list 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 the annotations, the description discloses that this is a human-facing moderation channel and that confirm:true is mandatory. It also reveals optional forwarding behavior (forward flag), which helps agents understand consequences.
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 short sentences carry the essential message: what the tool does, the forwarding option, and the mandatory confirmation. No redundant detail 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?
With full schema coverage of parameters and no output schema, the description is complete for an agent to invoke the tool correctly. It captures the core behavior, the human-moderation consequence, and the confirm requirement.
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?
All 8 parameters are fully described in the schema, so the description does not need to repeat them. It adds only the confirm requirement and optional statuses at a high level, which is already reflected 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 action ('Report an account'), the target audience ('your instance's moderators'), and the optional extension to specific statuses. This distinguishes it from sibling moderation actions like block_account or mute_account because it is specifically the reporting workflow.
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 clear context for when to use the tool: when an account should be brought to human moderators, with optional forwarding. It does not explicitly contrast against alternatives, but the reporting action is unique among siblings, and the confirmation requirement is stated.
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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavior context: it explicitly accepts multiple account identifier formats and resolves accounts the instance has never seen, which informs the agent about potential network/remote resolution and return completeness. No contradictions.
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 earn their place: the first summarizes the return contents, the second specifies accepted input formats, and the third highlights the remote-resolution behavior. The most critical information (what the tool returns) is front-loaded, with no fluff 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 read-only tool with two parameters, the description is complete: it states what is returned, what inputs are accepted, and how unknown accounts are handled. The output schema is absent, but the description lists the key result fields sufficiently for an agent to understand the return value. No critical operational detail is missing.
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 the schema has only 50% description coverage (the required 'acct' parameter lacks a schema description), the description compensates by clearly stating that the tool accepts '@user@instance', a bare local username, or a numeric id. This directly maps to the 'acct' parameter and provides the format information the schema omits. The 'account' parameter is already described in the schema, so the description adds meaning beyond it.
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 ('get') with a clear resource ('full profile for any account') and enumerates what is included (bio, counts, metadata fields, verification state, mutual follow status). It clearly distinguishes itself from sibling tools like get_account_statuses or get_relationships by focusing on the complete profile object.
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 when to use it: whenever a full account profile is needed, regardless of whether the account is known to the instance. It does not explicitly mention alternatives or exclusions, but the context is clear from the enumerated content and the note about resolving unseen accounts. This meets the 'clear context, no exclusions' level.
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 destructiveHint and readOnlyHint already flag mutation, the description adds irreversible consequences and exactly what is lost: boosts, replies, and favourites. It also states the explicit confirmation requirement, providing useful behavioral 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?
Four short sentences are front-loaded with purpose, then side effects, alternative, and confirmation requirement. There is no filler or repetition of schema details, so every sentence earns its place.
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 mutation with no output schema, the description covers what the tool does, what the id must refer to, the irreversible side effects, the preferred alternative, and the required confirm flag. An agent has enough information to invoke it correctly and safely.
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 67% schema coverage, `id` lacks a schema description, and the description fills part of that gap by saying the target must be one of the caller's own statuses. `account` and `confirm` are already well documented in the schema, so the description only needs to reinforce rather than re-explain them.
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 specific verb and resource: 'Delete one of your own statuses.' It clearly scopes the operation to the caller's own statuses and distinguishes the tool from edit_status, the main sibling that could be confused with it.
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?
It explicitly names the alternative for the common use case: 'To fix a mistake, prefer edit_status, which keeps all of that.' This tells an agent when not to use delete_status and which sibling to call instead.
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:

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

Score Badge

Copy to your README.md:

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

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