Integrates with Firebase Realtime Database to manage blog posts and comments, including creating, listing, retrieving, updating, and deleting posts, as well as moderating comments and retrieving site statistics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AR LABS Admin MCP Server Create a new AI prompt post about viral TikTok hooks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A full-access Model Context Protocol (MCP) server for managing AR LABS (Viral AI Prompts & Guides) via AI assistants like Claude Desktop, Cursor, Antigravity IDE, Cline, and Roo Code.
With this MCP Server, your AI assistant can:
create_post:
Create and publish new AI prompt articles directly to the website.
Accepts title, description, prompt text, and thumbnail (as a URL or Base64).
Auto-uploads Base64 images to ImgBB.
Automatically sends a OneSignal push notification to all subscribers!
list_posts:
List all published posts with search filtering and limits.
get_post:
Get full details of a specific post including complete prompt text and meta.
update_post:
Edit any post's title, description, prompt text, or thumbnail.
delete_post:
Delete a post from Firebase Realtime Database.
upload_image:
Direct image upload to ImgBB CDN (returns high-speed public CDN URL).
send_push_notification:
Send custom broadcast web push notifications to all website subscribers.
list_comments:
View user comments across posts.
delete_comment:
Moderate and remove spam comments.
get_site_stats:
Get quick stats: total posts count, total comments, database status, latest post.
Related MCP server: MCP WordPress Server
You can run this server anywhere directly from GitHub:
npx -y github:abdulrehmanfatehali1-ui/ar-labs-mcp-serverAdd the following to your claude_desktop_config.json:
{
"mcpServers": {
"ar-labs": {
"command": "npx",
"args": [
"-y",
"github:abdulrehmanfatehali1-ui/ar-labs-mcp-server"
]
}
}
}In your IDE MCP configuration:
{
"mcpServers": {
"ar-labs": {
"command": "npx",
"args": [
"-y",
"github:abdulrehmanfatehali1-ui/ar-labs-mcp-server"
]
}
}
}Add under MCP Servers settings:
Server Name: ar-labs
Command: npx
Arguments: ["-y", "github:abdulrehmanfatehali1-ui/ar-labs-mcp-server"]
Publish a new AI Prompt post/guide to the AR LABS website. Automatically handles image uploads (URL or Base64) and sends OneSignal push notifications to subscribers.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the post (e.g. 'Viral Cyberpunk Girl Midjourney Prompt') | |
| prompt | Yes | The exact AI prompt text that users can copy | |
| description | Yes | Overview description, guide instructions, and tips for the user | |
| imageBase64 | No | Base64 string of the thumbnail image (will be automatically uploaded to ImgBB) | |
| thumbnailUrl | No | Direct URL of the thumbnail image (or provide imageBase64) | |
| sendNotification | No | Whether to send a push notification to subscribers (default: true) | |
| notificationHeading | No | Custom heading for the push notification (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to lean on, so the description carries the full transparency load. It discloses major side effects: publishing to the website, auto-uploading images via URL or Base64, and sending push notifications to subscribers. It does not mention public visibility className or error behavior, but the core publishing side effects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence names the action and target; the second summarizes automatic side effects. It is tightly scoped and easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main flow: publishing, image upload, and notification. However, with no output schema and no annotations, it does not mention return values or clarify that sendNotification defaults to true and can be disabled. These details are important for agent decision-making even if the schema describes the parameter, so the description is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description only summarizes 'image uploads (URL or Base64)' and does not add new parameter-level meaning beyond what the schema already provides for imageBase64 or thumbnailUrl. No parameter is misleading, but the description does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Publish a new AI Prompt post/guide to the AR LABS website,' which identifies the action, resource, and destination clearly. The word 'new' strongly distinguishes it from sibling update_post, and the overall intent is distinct from list/get/delete posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates that image uploads and OneSignal push notifications are handled automatically, signaling that creators do not need to call upload_image or send_push_notification separately. It does not explicitly state when not to use it (e.g., for editing existing posts), but the 'new' keyword and sibling context make the intended use fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a comment by its ID from Firebase Realtime Database.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Firebase comment ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the deletion operation but does not disclose permanence, idempotency, or side effects (e.g., if the comment doesn't exist). The word 'delete' implies irreversibility, but the description lacks explicit warnings or context about data loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with no output schema, the description is adequate. It explains what it does and the required input. It could mention expected results or error cases, but it is complete enough for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description already explaining the ID's purpose. The tool description adds no additional semantics beyond re-stating 'by its ID,' so it meets the baseline for fully documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (comment), and the identifier (ID). It is unambiguous and distinct from sibling tools like delete_post, and it specifies the data store (Firebase Realtime Database).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when deleting a comment by ID) and provides clear context. It does not explicitly mention alternatives or exclusions, but the operation is self-evident and no competing delete tool for comments exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a post from AR LABS by its Firebase ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the post to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'permanently delete' which implies irreversibility, but it doesn't disclose potential side effects (e.g., cascading deletion of comments, auth requirements, or rate limits). The description is minimal and leaves important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No wasted words; it efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is thin. It doesn't mention what happens after deletion (e.g., return value, confirmation), any side effects, or error conditions. Given the tool's simplicity (one param), it's adequate but lacks completeness for a permanent action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'id' with a clear description. The tool description adds the context that the ID is a Firebase ID, which is slightly beyond the schema, but the schema already explains the parameter adequately. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (permanently delete) and the resource (a post from AR LABS) with the identifier (Firebase ID). It distinguishes from siblings like update_post and create_post, though it doesn't explicitly contrast with delete_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as delete_comment for comments or update_post for non-destructive changes. The description implies deletion is permanent but doesn't provide context on prerequisites or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full details and prompt of a specific post by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the post in Firebase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must convey behavior. It clearly indicates a retrieval operation ('Retrieve'), which is transparent. However, it does not disclose potential error conditions (e.g., non-existent ID) or any side effects. For a simple read tool this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the exact purpose with no filler. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation with no output schema, the description is sufficient. It covers what the tool does and the key input. It lacks explicit mention of response format, but that's often inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'id' parameter, including its type and meaning. The description adds 'by its ID', which rephrases the schema without adding new meaning. Baseline 3 is appropriate since the schema dominates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details and prompt of a specific post by ID. It uses a specific verb ('Retrieve'), specifies the resource (post), and narrows scope ('specific post by its ID'), distinguishing it from sibling tools like list_posts or update_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a post ID) but does not explicitly mention when to prefer this over alternatives like list_posts or when not to use it. It lacks explicit 'when to use vs when not' guidance, so the agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get general overview stats for AR LABS (total posts, total comments, latest post, database status).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It explicitly lists the returned metrics (total posts, comments, latest post, DB status) and implies a read-only operation via 'Get'. It does not state side-effects, but none are implied or suggested. This is adequate for a simple stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'Get' and resource, and lists the specific stats. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema. The description enumerates what will be returned (total posts, comments, latest post, DB status), making it self-sufficient for an agent to understand outcome. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the rule for 0 params sets baseline 4. The description adds no param information because there are none. It does clarify the output contents, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves overview stats for AR LABS, listing specific metrics (total posts, total comments, latest post, database status). This distinguishes it from sibling update/upload/delete tools, which are content mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for site-wide overview stats, contrasting with resource-specific tools. It does not explicitly state when not to use it, but the 'overview' framing makes its purpose clear among CRUD siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments left by users on the website, with optional filtering by postId.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | No | Optional Firebase Post ID to filter comments for a specific post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action. It doesn't mention that it's read-only, return format, pagination, or any error conditions. The description is too sparse to adequately inform an agent of side effects or guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose and includes the optional filter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter, the description covers the essentials but leaves out details like pagination, ordering, or response structure. Since there is no output schema, some additional context about the return value would be helpful, but it's adequate for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the postId parameter. The description only restates 'optional filtering by postId' without adding new meaning, meeting the baseline but adding no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('comments') and adds context 'left by users on the website.' It clearly distinguishes from sibling tools like list_posts by focusing on comments, and the optional postId filter is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied—it lists comments, but there is no explicit guidance on when to use this tool versus alternatives. No mention of alternatives or exclusions, so it relies on the reader to infer 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.
Retrieve a list of all posts/AI prompts from AR LABS with sorting, search, and pagination limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return (default: 20) | |
| search | No | Optional keyword to search in titles, descriptions, and prompt text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full burden. It discloses capabilities (sorting, search, pagination limits) but omits details like read-only nature, default behavior, auth requirements, or response format. It provides some transparency but not comprehensive coverage for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. However, it includes a potentially misleading 'sorting' term not backed by the schema, which slightly reduces clarity. No wasted words, but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description covers the basics (search, pagination) but leaves gaps: no mention of default limit behavior, sorting mechanism, or what fields the returned posts contain. It is minimally sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (limit and search), so baseline is 3. The description mentions 'search' and 'pagination limits' but does not add detailed meaning beyond the schema. It also mentions 'sorting' which is not reflected in the schema, creating a minor inconsistency but not detracting significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a list') and the resource ('posts/AI prompts from AR LABS'), and includes scope hints like sorting and pagination. It distinguishes from siblings like 'list_comments' and 'get_post' by focusing on listing all posts, though 'all' is qualified by pagination limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It implies listing use case, but doesn't mention when not to use it (e.g., for a single post use get_post) or any exclusions. The description only states the action without context on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a custom web push notification to all AR LABS subscribers via OneSignal.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Target URL when user clicks (default: https://www.tubeseekify.online/) | |
| heading | Yes | Title of the notification (e.g. '🔥 New Viral Prompts Added!') | |
| message | Yes | Body text of the notification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the broadcast scope ('all AR LABS subscribers') but does not mention potential side effects like irreversibility, rate limits, or impact on users. This is adequate for a simple action but could be enhanced with a warning about sending to all subscribers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key information. Every word is purposeful, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward send tool with a fully documented schema and no output schema, the description is sufficient. It covers the action, audience, and method. It could be slightly enriched with a note about response handling, but this is not critical for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive text for each parameter (url, heading, message) directly in the schema. The tool description adds no additional meaning or context beyond what the schema already offers, meriting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send), the resource (web push notification), the target audience (all AR LABS subscribers), and the method (via OneSignal). It is specific and distinguishes this tool from sibling tools that manage posts and comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: sending a broadcast notification to all subscribers. While it doesn't explicitly exclude other tools or provide alternatives, the context is unmistakable given the distinct nature of push notification delivery compared to content management siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing post's title, description, prompt, or thumbnail.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique Firebase ID of the post to update | |
| title | No | Updated title (optional) | |
| prompt | No | Updated AI prompt text (optional) | |
| description | No | Updated description (optional) | |
| imageBase64 | No | Updated image as base64 string to upload to ImgBB (optional) | |
| thumbnailUrl | No | Updated direct thumbnail image URL (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Update', which signals mutation, but does not explain side effects such as whether imageBase64 triggers an ImgBB upload and subsequent thumbnail update, whether changes are reversible, or what response is returned. This lack of detail is insufficient for a mutation tool with multiple field types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb 'Update' and the object 'existing post'. It efficiently lists the core updatable fields. However, it could be better structured by clarifying that multiple fields can be updated simultaneously and by mentioning the imageBase64 option. Still, it is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is far too brief. It does not explain how partial updates work (all fields optional except id), the behavior of imageBase64 (upload to ImgBB), whether the thumbnailUrl is mutually exclusive with imageBase64, or what the tool returns (e.g., updated post object). The absence of such critical context makes it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter having its own description (e.g., 'Updated title (optional)'). The tool description adds no additional meaning beyond repeating a subset of field names (title, description, prompt, thumbnail) and even uses 'thumbnail' generically, which could confuse the reader about the distinction between thumbnailUrl and imageBase64. Given high schema coverage, the baseline of 3 is appropriate; the description doesn't significantly augment parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing post'), and lists the specific fields that can be updated: title, description, prompt, or thumbnail. This distinguishes it from sibling tools like create_post and delete_post. However, it omits the imageBase64 parameter (which updates the image via ImgBB) and the phrase 'or' implies only one field can be changed at a time, whereas multiple fields can be updated. Thus, slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing posts (as opposed to create_post for new ones), and the required id field indicates you must already have a post. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any preconditions (e.g., must have the post id, or that imageBase64 is an alternative to thumbnailUrl). Absence of exclusions or alternative tool mentions keeps this at a basic level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload any image to ImgBB CDN and get back a public high-speed URL.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name/filename for the image | |
| image | Yes | Base64 encoded image string OR remote public image URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears the full burden. It mentions offloading to a third-party CDN and returning a public URL, but for a mutation tool with no annotations it fails to disclose return format, file size limits, link expiration (e.g., ImgBB's 30-day retention on free tier), or authentication requirements. The 'high-speed' language is promotional filler that doesn't add behavioral substance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, scannable sentence that front-loads the action and outcome. Every word earns its place; 'high-speed' is mildly promotional but harmless. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no nested objects, enums, or output schema, the description is nearly adequate end-to-end. However, given no annotations, a bit more context (e.g., rate limits, typical latency, or that the CDN URL may be temporary) would elevate this to genuinely helpful rather than merely functionally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so per guidelines the baseline is 3. The description adds no parameter-specific context beyond the schema — e.g., it doesn't clarify acceptable image formats, size limits, URL encoding rules, or what 'public' implies about accessibility. Baseline of 3 holds because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload'), resource ('any image to ImgBB CDN'), and clear outcome ('get back a public high-speed URL'). It clearly distinguishes this from all siblings (get_site_stats, create_post, etc.), none of which handle image uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (whenever an image upload is needed) and differentiates from siblings by being the only upload-capable tool. However, it provides no explicit guidance on when NOT to use it, no prerequisites (e.g., auth), and no alternative tool names, relying on obviousness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: posts CRUD, comments list/delete, stats, image upload, and push notifications. No overlapping functionality, so an agent can easily select the right tool for a given task.
All tool names follow the verb_noun pattern with snake_case (e.g., list_posts, get_post, update_post, delete_post). Retrieval actions use 'get_' for single items and 'list_' for collections, maintaining a consistent and predictable naming scheme.
With 10 tools, the set covers the core admin operations without being excessive or sparse. Each tool serves a specific function relevant to the server's purpose (managing posts, comments, stats, images, and notifications), making the count well-balanced.
The tool set provides full CRUD for posts, list/delete for comments, plus stats, image upload, and push notifications. Minor gaps exist, such as no single-comment fetch or comment update action, but the core admin operations are well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
WordPress MCP server: publish posts, AI images, SEO and full site management, self-hosted
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
WordPress MCP server: generate SEO posts, AI images, autoblog & WooCommerce on your self-hosted site
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/abdulrehmanfatehali1-ui/ar-labs-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
