clippy
Server Details
AI agents can Create rooms and store/retrieve text and images, and hand link to humans no sign-up.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: room creation, text/image storage, item listing, deletion, password management, and room status checking. No two tools overlap in functionality; descriptions make the differences obvious.
All tool names follow a consistent kebab-case verb-noun-tool pattern (e.g., clear-room-tool, store-item-tool), making the naming predictable and easy to understand.
With 9 tools, the server covers the core operations needed for a shared clipboard room without being excessive or too sparse. Each tool serves a necessary function in the workflow.
The tool set provides full lifecycle coverage: create room, store text/images, list items, update text, delete individual/clear all items, set password, and check room status. No obvious gaps for the intended domain.
Available Tools
9 toolsclear-room-toolClear Clippy RoomADestructiveInspect
Delete ALL items in a Clippy room (and their images). Use with care — this wipes everything shared in the room and cannot be undone. The room itself continues to exist and can be reused.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The room code that was cleared. |
| cleared | Yes | Number of items that were deleted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond the destructiveHint annotation by stating that actions cannot be undone, that images are also deleted, and that the room persists. This provides complete behavioral clarity for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences. The first sentence states the core action, and the second provides critical warnings and a note about room persistence. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main effect, destruction scope, and irreversibility adequately. It does not discuss return values (handled by output schema) or parameter requirements (handled by schema). A mention of when to use password vs owner_token would improve completeness, but is not critical given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides, such as the purpose of password or owner_token.
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 'Delete ALL items' and clearly identifies the resource 'Clippy room (and their images)'. It explicitly states that the room continues to exist, distinguishing it from other deletion tools like delete-item-tool.
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 includes a strong warning about destructive action and irreversibility, indicating careful use. However, it does not explicitly mention when not to use it or suggest alternatives like delete-item-tool for selective deletion, which would further clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-room-toolCreate Clippy RoomAInspect
Create a brand-new Clippy room and get back its 6-character code, a private owner_token, and a share URL. Use this when you want a fresh shared clipboard to push content to a user (hand them the URL) or to coordinate with other agents. Keep the owner_token private — it grants password control over the room.
| Name | Required | Description | Default |
|---|---|---|---|
| password | No | Optional. Lock the new room with this password so only holders of the password (or the owner_token) can read/write it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Human-shareable URL that opens the room on any device. |
| code | Yes | The new 6-character room code. |
| locked | Yes | Whether the room is password-protected. |
| owner_token | Yes | Private token granting password control over the room. Keep secret. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: creation + return values + owner_token grants password control. Does not mention limits or default state, but sufficient for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with core function, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 0 required params and a clear output schema, the description fully covers what the agent needs: purpose, return values, and privacy note.
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% and already describes the password parameter. The description adds no new parameter meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Create' and resource 'Clippy room', lists return values (code, owner_token, URL), and distinguishes from sibling tools like store-item or list-items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you want a fresh shared clipboard to push content to a user or to coordinate with other agents.' Also advises to keep owner_token private. Could include explicit not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete-item-toolDelete Clippy ItemADestructiveInspect
Delete a single item from a Clippy room by its item id (the id returned by store-item / list-items). Any images attached to the item are removed too. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). | |
| item_id | Yes | The item id (UUID) to delete. | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The room code that was targeted. |
| deleted | Yes | Whether an item was actually deleted (false if it did not exist). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true. The description adds that images attached are removed and that the action cannot be undone. This provides valuable behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. The action is front-loaded. Every sentence adds value.
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 annotations (destructiveHint) and output schema existence, the description covers the key aspects: what is deleted, effect on images, irreversibility. No gaps identified.
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 detailed parameter descriptions. The tool description adds little beyond the schema: it mentions the item id source but the schema already says it's a UUID. For room, it is less specific than the schema. 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 tool deletes a single item by its item id, specifies that the id comes from store-item or list-items, and notes that attached images are removed. It distinguishes from sibling tools like clear-room-tool (which clears all items) by specifying 'single item'.
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 when deleting one specific item. It does not explicitly compare to clear-room-tool for bulk deletion, but the phrasing 'single item' provides context. Lacks explicit 'when not to use' or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-items-toolList Clippy Room ItemsARead-onlyIdempotentInspect
Read the items in a Clippy room (newest first). Use this to pick up text a user or another agent left for you, or to see what is currently in a shared room. Pass since (a millisecond timestamp from a previous call) to fetch only items added after that point. Image items include direct image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). | |
| limit | No | Optional. Maximum number of items to return (1–100). Defaults to 100. | |
| since | No | Optional. Return only items created strictly after this Unix timestamp in milliseconds. Use the `now` value from a previous call to poll incrementally. | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| now | Yes | Server time in Unix milliseconds; pass as `since` next call to poll incrementally. |
| code | Yes | The room code that was read. |
| count | Yes | Number of items returned. |
| items | Yes | The matching items, newest first. |
| locked | Yes | Whether the room is password-protected. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses ordering (newest first) and the behavior of the since parameter for incremental reads. It also notes that image items include direct image URLs, adding value over 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core function, then provides usage guidance and relevant parameter details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 1 required), the description covers the main use case, incremental polling, and a special case for images. It does not explicitly state the return format, but the presence of an output schema and the context of 'items' makes it sufficiently 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?
With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the since parameter's purpose and the presence of image URLs in items, which is not in the schema. This enhances understanding beyond the raw parameter descriptions.
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 reads items from a Clippy room with a specific order (newest first). It distinguishes itself from sibling tools like store-item-tool and delete-item-tool by focusing on reading, not writing or deleting.
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?
Provides explicit use cases: picking up text left by a user or agent, seeing the current room state, and incremental polling via the since parameter. It does not explicitly mention when not to use it, but the sibling context implies it for reading only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
room-status-toolClippy Room StatusARead-onlyIdempotentInspect
Check whether a Clippy room exists, whether it is password-protected, and how many items it holds — without reading the contents. Handy before deciding to read or write, or to confirm a code a user gave you is valid.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Human-shareable URL for the room. |
| code | Yes | The room code that was checked. |
| exists | Yes | Whether the room currently exists. |
| locked | Yes | Whether the room is password-protected. |
| itemCount | Yes | Number of items currently in the room. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds 'without reading the contents,' emphasizing non-invasive nature, reinforcing safety 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guidance. Every word earns its place; 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?
Given low complexity (1 param, no enums) and presence of output schema, description adequately covers functionality and usage context for the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description elaborates: '6-character room code (or a Clippy share URL / #CODE link),' adding format details beyond the schema's generic string description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks if a Clippy room exists, is password-protected, and its item count, using specific verbs and resource. It distinguishes from sibling tools like create-room or store-item.
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?
Provides explicit context: 'before deciding to read or write, or to confirm a code a user gave you is valid.' Not explicit about when not to use, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set-room-password-toolSet Clippy Room PasswordAInspect
Lock or unlock a Clippy room. Requires the room owner_token (returned by create-room). Pass a password to lock the room; pass an empty password to remove the lock. Only the owner can change this.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). | |
| password | No | The new password to lock the room with. Pass an empty string to remove the password and make the room open. | |
| owner_token | Yes | The room owner_token proving you own this room. Required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The room code whose lock state changed. |
| locked | Yes | Whether the room is now password-protected. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It covers the main behavior (locking/unlocking, owner restriction) but does not mention error handling, side effects, or return values. The existence of an output schema reduces the need to describe returns, but some transparency is missing.
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?
Three concise sentences, front-loaded with the main purpose. Every sentence provides essential information without redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, output schema present), the description covers the key aspects: purpose, prerequisites, and behavior. It is complete enough for an agent to understand usage, though it could mention error conditions or the return value briefly.
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 baseline is 3. The description adds a bit of context (owner_token from create-room, empty password for unlock) but largely reiterates what the schema already provides. No significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lock or unlock a Clippy room', specifying the verb and resource. It distinguishes itself from sibling tools like 'room-status-tool' by focusing on password management, not information retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: requires owner_token, only owner can change, and explains how to lock/unlock with password. However, it does not explicitly mention when to use this tool versus alternatives like 'room-status-tool' or 'clear-room-tool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store-image-toolStore Image in Clippy RoomAInspect
Post one or more images (PNG, JPEG, GIF, or WEBP) to a Clippy room so they appear on every device watching it, optionally with a text caption. Pass each image as a base64 string or a data: URI. The room is created if it does not exist. Subscribed devices get a push notification. Returns the stored item, including direct URLs to fetch each image.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). The room is created if new. | |
| text | No | Optional caption to store alongside the image(s). Up to 200,000 characters. | |
| device | No | Optional short label for who is posting (max 64 chars). Defaults to "AI Agent". | |
| images | Yes | One or more images, each a base64-encoded PNG/JPEG/GIF/WEBP or a data: URI (e.g. "data:image/png;base64,iVBOR..."). Up to 10 images, 10 MB each. | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Human-shareable URL that opens the room on any device. |
| code | Yes | The room code the image was stored in. |
| item | Yes | The stored item, including image URLs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: room auto-creation, push notifications, return includes direct URLs, and constraints (max images, size, caption length). No contradictions with empty 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?
Three sentences, each adding essential information: purpose, input format, return value. No redundancy, well front-loaded.
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 output schema exists, description covers all necessary aspects: input requirements, constraints, return details. No gaps for a post 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?
Adds meaning beyond schema: explains base64/data URI format, device default, room format flexibility. Schema coverage is 100%, so baseline 3; description adds 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?
Clearly states the verb (post) and resource (images to Clippy room), distinguishes from sibling tools like store-item-tool by specifying images and push notification behavior.
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?
Provides clear context for when to use (sending images to a room), mentions auto-creation and push notifications, but lacks explicit alternatives or 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.
store-item-toolStore Item in Clippy RoomAInspect
Post a piece of text to a Clippy room so it appears on every device and agent watching that room. The room is created automatically if it does not exist yet. Subscribed devices receive a push notification. This is how you "send" something to a user or leave a note for another agent. Returns the stored item.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). The room is created if new. | |
| text | Yes | The text content to store (a snippet, link, message, etc.). Up to 200,000 characters. | |
| device | No | Optional short label for who is posting (max 64 chars). Defaults to "AI Agent" so humans can tell agent posts apart. | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Human-shareable URL that opens the room on any device. |
| code | Yes | The room code the item was stored in. |
| item | Yes | The stored item. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses room auto-creation, push notifications, and return value. Lacks details on rate limits or error handling but covers key behaviors.
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?
Four concise sentences, each adding value. Front-loaded with main purpose, then details and usage context. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full parameter coverage and an output schema, the description adequately explains behavior and return value. Sibling tools are diverse but this tool's purpose is clear without requiring cross-references.
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%, and description adds meaningful context: room format, text length limit, default device label, and conditions for password/owner_token. Enhances understanding 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 uses a specific verb ('Post') and resource ('a Clippy room'), clearly stating the tool stores text. It distinguishes from siblings like store-image-tool by specifying 'piece of text'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: 'send something to a user or leave a note for another agent.' However, it does not explicitly contrast with sibling tools like update-item or list-items, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-item-toolUpdate Clippy ItemAInspect
Edit the text of an existing item in a Clippy room, identified by its item id (the id field returned by store-item / list-items). Image bytes are immutable; this changes only the text.
| Name | Required | Description | Default |
|---|---|---|---|
| room | Yes | The 6-character room code (or a Clippy share URL / #CODE link). | |
| text | Yes | The new text. For a text-only item this cannot be empty — delete it instead. | |
| item_id | Yes | The item id (UUID) to edit, as returned in the `id` field of a stored/listed item. | |
| password | No | Required only if the room is password-protected and you are not using owner_token. | |
| owner_token | No | Optional. The room owner_token; bypasses the password on a locked room. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The room code containing the item. |
| item | Yes | The updated item. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description discloses immutability of image bytes and text constraints, adding value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters covered, output schema exists, and description addresses key behavioral constraints for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already includes descriptions; the description only adds minimal context (e.g., origin of item_id) not contributing significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edit' and the resource 'text of an existing item', distinguishing it from store-item and delete-item siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides when to use (edit text) and when not (images immutable, empty text deletion), but does not explicitly exclude other siblings like store-image-tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!