arena-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource/action combination: search, channel contents, block metadata, block connections, user profile, user contents, and connection operations. Create_block vs connect_block are clearly separated as new vs existing, and channel contents vs user contents are disambiguated by the resource prefix.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: search_*, get_*, create_*, connect_*, disconnect_*, move_*. The naming convention is predictable and uniform across the entire toolset.
Tool Count5/5
11 tools is well-scoped for an Are.na integration. Each tool serves a meaningful purpose without redundancy or an overwhelming number of operations.
Completeness4/5
Core read, search, create, and curation workflows are well covered, including channel contents, block details, user content, and connection management. Missing update/delete operations for channels and blocks is a notable gap, but agents can still complete primary workflows.
Average 3/5 across 11 of 11 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'reposition' and reveals nothing about ordering semantics, side effects, permissions, mutation risk, idempotency, or response behavior. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. While it is structurally concise and easy to parse, the brevity comes at the expense of useful substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the moderate complexity of a three-parameter mutation with an enum and an optional position field, the description is largely uninformative. There is no output schema, no annotation layer, and no explanation of movement modes, constraints, or expected results, so an agent cannot reliably invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning to any parameter. It does not explain what `movement` values do, whether `position` is required for `insert_at`, or how `connection_id` identifies the item. An agent must guess the relationship between the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reposition') and the resource ('a connection within a channel'), making the tool's basic purpose obvious. It is also distinguishable from sibling tools like connect_block and disconnect_connection, though it does not explicitly mention any competing reorder-like 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 when-to-use guidance, no prerequisites, and no mention of when a sibling tool would be preferable. The context is implied at best: an agent should call this only when repositioning an existing connection, but nothing clarifies alternatives such as disconnect/connect or read-only inspection 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says a channel is created, without mentioning authentication requirements beyond 'authenticated user', side effects, idempotency, permission needs, or what happens on duplicate titles. For a mutation tool, this is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It efficiently communicates the core purpose. However, it is so terse that it omits necessary context, though this is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, four parameters, and zero schema description coverage, the description should provide substantial context. It provides only the basic action and owner. Missing details include required versus optional parameters, visibility semantics, group_id meaning, and any behavioral consequences of creating a channel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters. It does not explain that title is required, what group_id refers to, what visibility values mean, or how description is used. The description adds no value beyond the raw schema field names.
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 new channel for the authenticated user.' This clearly identifies the operation and is distinct from sibling tools like get_channel_contents and create_block. However, it does not clarify what a 'channel' is or how it differs from a 'block', leaving slight room for ambiguity.
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 alternatives such as create_block or search_arena. There are no conditions, prerequisites, or exclusions provided. Usage must be inferred 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?
With no annotations, the description carries the full burden. It discloses that the operation is a read and that only one page is returned, but it says nothing about defaults, ordering behavior, return format, or side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is compact and front-loaded, which is good. However, it is under-specified for a tool with five parameters and no other documentation; it is concise but not appropriately sized in terms of content.
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?
No annotations, no output schema, 0% parameter coverage, and a terse purpose statement leave the definition incomplete. An agent cannot infer pagination defaults, return structure, or how user_id and sort interact without additional help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies id_or_slug identifies the channel and that page/per control pagination, but it does not explain the sort enum, user_id filtering, or constraints. This is insufficient for five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('read') and resource ('channel contents') and scopes it to 'one page,' which clearly distinguishes it from sibling tools like get_user_contents. It stops short of explicitly naming alternatives, so it does not fully maximize differentiation.
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 such as search_arena or get_user_contents. There are no exclusions or contextual cues to help an agent select among siblings.
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?
No annotations are provided, so the description carries the full disclosure burden. It only implies a read operation and pagination with 'List one page,' but it doesn't disclose required identification, defaults, response format, scoping, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy and is front-loaded. It is concise, though it is terse to the point of under-specification.
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 five parameters, no output schema, and no annotations, this description is not sufficient to call the tool correctly. Critical information about the required identifier, pagination parameters, and content type filtering is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no semantic meaning for any of the five parameters. The required id_or_slug, the sort enum, and the type enum are completely unexplained.
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 ('List') and resource ('user content'), and it indicates pagination with 'one page.' This distinguishes it from siblings like get_channel_contents, though it doesn't explain what counts as user content or how it relates to get_user.
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. It neither states explicit use cases nor mentions exclusions, so an agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries the full disclosure burden. It does add genuine behavioral value by disclosing the v3-to-v2 fallback for premium-gated content and stating results are normalized, which hints at output shape variance. However, it omits other behavioral traits such as authentication needs, rate limits, or whether results from the fallback differ in structure.
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 waste: the first states the core action and output characteristic, the second adds the fallback behavior. The most important information is front-loaded and every clause 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 search tool with 13 parameters, three enums, pagination controls, and no output schema or annotations, two sentences are inadequate. Missing context includes default sort/scope/type behavior, what 'normalized' means for the returned shape, pagination defaults, and how the version fallback might alter response fields. The description is sufficient to call the tool with the required query alone, but not to use it well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% while the description mentions no parameters at all, so it fails to compensate for the gap. The schema's self-documenting enums (sort, type, scope) and the implied 'query' requirement help slightly, but 13 parameters — including opaque ones like ext, after, seed, include_raw, and the three ID filters — receive zero semantic explanation.
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 ('Search Are.na') and adds what the tool returns ('normalized results'), which clearly distinguishes it from the get_* sibling tools that fetch specific resources by ID. However, it doesn't explicitly contrast itself with any sibling, 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 on when to use this tool versus the sibling get_channel_contents, get_user, or get_block_details tools, nor any exclusion criteria. The v3/v2 fallback note describes internal behavior but not usage context. An agent must infer that 'search' is for discovery while 'get' is for direct retrieval.
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?
With no annotations, the description must carry behavioral disclosure itself; it does state that this is a read operation and that it returns block metadata plus connected channels. However, it does not mention permissions, error behavior, or how 'complete metadata' is represented, leaving some uncertainty about side effects and outputs.
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 one concise, front-loaded sentence with no filler. It immediately communicates the action and resource and every word adds value.
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 with one integer parameter, but there is no output schema and no annotations, so the description is responsible for communicating return shape and operational context. It gives a basic map (metadata plus connected channels) but does not specify how channels appear, whether there are limits, or what happens for invalid ids.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to clarify the lone id parameter. It only says 'a block', leaving the agent to infer that id is the block identifier and does not describe valid values or edge cases.
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 clear action ('Read') and names the resource ('complete metadata for a block plus connected channels'), which differentiates it from siblings like get_block_connections or get_channel_contents. However, 'complete metadata' is somewhat open-ended, so it does not fully specify the exact contents of the response.
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 choose this tool over alternatives. The sibling list includes related tools such as get_block_connections, but the description does not state criteria, exclusions, or conditions that would help an agent select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly labels the operation as read-only ('Read'), which is the key behavioral trait, and no annotations are present to cover safety. However, it does not disclose authentication needs, error behavior, or response characteristics, leaving some behavioral burden unmet.
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 with no filler and front-loads the verb and object. Every word earns its place, and there is no redundancy with the title or schema.
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 one-parameter read operation, the description conveys enough to make a basic call. However, it omits differentiation from get_user_contents and does not clarify id_or_slug semantics or return shape, leaving clear gaps despite the low complexity.
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 has 0% description coverage, so the description needed to compensate for parameter meaning. It never mentions id_or_slug or how to format it, though the parameter name is mildly self-explanatory. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('user profile details'), making the tool's function immediately clear. It does not explicitly distinguish it from the sibling get_user_contents, though 'profile details' hints at the difference.
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 on when to use this tool versus siblings like get_user_contents or search_arena. There are no prerequisites, context cues, or exclusions, so the agent must infer usage from the tool name and minimal description.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the connect action and does not mention side effects, whether existing connections are replaced, authorization requirements, idempotency, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the primary action and target, though it is terse.
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?
placeholder
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 0% schema description coverage, the description must compensate for parameter meaning. It clarifies that block_id refers to an existing block and that channel_ids are one or more channels, but it says nothing about the position parameter, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('connect') plus resource targets ('existing block', 'one or more channels'), making the operation clear. It is also distinguishable from sibling tools like create_block, disconnect_connection, and move_connection.
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 such as move_connection or disconnect_connection. There are no prerequisites, exclusions, or alternative tool references, so the agent must infer usage only from the action name.
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?
With no annotations provided, the description must carry the behavioral disclosure. It does clearly present the operation as a read-only listing, which is the most important behavior. But it does not mention pagination, filtering semantics, ownership scoping (ALL/OWN/EXCLUDE_OWN), response shape, or any authentication or rate-limit implications, which are relevant for a tool with this many parameters.
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 direct sentence with no filler or redundancy. It is appropriately front-loaded with the core action and resource. It is not rated 5 because the extreme brevity leaves out context that the complexity of the schema suggests would be helpful.
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?
This tool has five parameters, two enums, no output schema, and no annotations. The description explains only the basic purpose, leaving the meaning and intended use of most parameters undocumented. An agent would struggle to correctly use optional parameters like filter and sort or to interpret the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It only implies the 'id' parameter via 'a block appears' and says nothing about per, page, sort, or filter. An agent cannot infer the meaning of the enum values (ALL, OWN, EXCLUDE_OWN) or the pagination controls from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('channels'), and the condition that selects them ('where a block appears'). This distinguishes it from write-oriented siblings like connect_block and inverse-query siblings like get_channel_contents, so an agent can infer what the tool does without opening the schema.
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 case is implied: when you need to find which channels contain a given block, this tool answers that. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusion criteria, leaving some ambiguity for an agent deciding between this and similar lookup 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?
No annotations exist, so the description carries the full burden. It states the destructive action ('Remove'), but does not disclose side effects, irreversibility, permissions, or consequences for dependent data. This is similar to an 'Update' description that implies mutation without detailing effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and target. Every word earns its place with no filler or redundancy.
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 one-parameter delete-like operation, the description covers the core action and parameter meaning. However, with no annotations and no output schema, it omits behavioral consequences and usage context, leaving some gaps for an agent to manage.
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 0% and the only schema info is that connection_id must be a positive integer. The phrase 'by ID' clarifies that connection_id is the identifier of the connection to remove, which adds meaning beyond the schema, though it does not explain where to obtain the ID or any additional constraints.
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 the specific verb 'Remove' with a clear resource, 'a connection', and the identifier method 'by ID'. This clearly distinguishes it from sibling tools like connect_block, move_connection, and get_block_connections.
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 about when to use this tool versus alternatives such as connect_block, move_connection, or get_block_connections. No context, prerequisites, or exclusions are provided.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal one important behavioral trait: local file paths are rejected and public URLs must be used. However, it does not mention mutability, reversibility, permissions, or what happens on invalid input.
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 front-loaded, and the URL constraint is a necessary usage detail that 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?
Given 8 parameters, no annotations, no output schema, and zero schema-level parameter descriptions, this short description leaves significant gaps. An agent would still need more information about required parameter semantics, return behavior, and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It vaguely maps to 'value' by mentioning text/link/media and to 'channel_ids' by mentioning channels, but optional parameters like alt_text, insert_at, and description are left unexplained. The 8-parameter surface is largely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: create a text/link/media block and connect it to channels. This distinguishes create_block from siblings like create_channel and connect_block, since it covers both creation and initial channel connection.
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 this tool: for creating a new block and connecting it to channels. It also provides a clear input prerequisite (public URLs, not local file paths), but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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