token-of-esteem
Server Details
A press your agent can commission: a funny, personalized printed booklet, mailed as a gift.
- Status
- Unhealthy
- 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.2/5 across 12 of 12 tools scored. Lowest: 3.3/5.
Each tool targets a distinct action or resource (create, cancel, list, get, validate, etc.) with no overlapping purposes. The difference between list_gifts and get_gift, or create_gift and validate_brief, is clear and well-defined.
All tool names follow a consistent verb_noun pattern (e.g., cancel_gift, create_setup_link, list_voices). Verbs are uniform (cancel, create, get, list, validate) and nouns are appropriately singular or plural.
With 12 tools covering the full lifecycle of ordering a booklet gift, the count is well-scoped. Each tool serves a clear purpose without redundancy, and the surface is neither too thin nor overly heavy.
The tool set covers all major operations for the domain: listing available options (formats, voices, models, recipients), pricing, validation, creation with payment, cancellation, tracking, account management, and setup. No obvious gaps are present.
Available Tools
12 toolscancel_giftAInspect
Cancel an in-flight gift and receive the refund amount. Free. Only possible before the booklet goes to print; once printing has started it fails with cancel_too_late. Pass the gift_id from create_gift and an optional reason for your records.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional human-readable reason for the cancellation, recorded on the order. | |
| gift_id | Yes | The gift_id returned by create_gift, identifying the order to cancel. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses refund, free status, and failure case (cancel_too_late). Could add idempotency or irreversibility but sufficient.
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, no waste. Front-loaded with core action and refund. Efficiently communicates all needed info.
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?
No output schema, but description mentions refund amount and error. Complete for a simple cancellation 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 covers both params with descriptions. Description adds context: gift_id from create_gift, reason optional and for records. Adds value beyond 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?
Clearly states 'Cancel an in-flight gift' which specifies verb and resource. The description also mentions refund and free, and distinguishes from sibling tools like create_gift.
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 the timing constraint: only possible before printing starts. Also mentions prerequisite gift_id from create_gift. Lacks explicit when-not-to-use but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_giftAInspect
Place the order: write, print, and mail the booklet. CHARGES the buyer. The recipient is whoever you name in recipient, which may be your own user. Idempotent on idempotency_key for 24 hours. Pass shared_payment_token to pay tokenlessly, or omit it to charge the account's saved card.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Structured brief about the recipient: what to celebrate, what to tease gently, and the inside jokes worth knowing. | |
| format | No | Booklet format. Only manual_v1, a 16-page booklet, is supported today. | |
| recipient | Yes | Who receives the booklet and where to mail it. Pass an inline recipient with a US ship_to, or a saved recipient_id. | |
| agent_note | No | Optional note from the agent, stored with the order for support. Never printed in the booklet. | |
| idempotency_key | Yes | Caller-chosen key that makes this order idempotent for 24 hours. Reuse the same key to retry safely without charging twice. | |
| preview_before_print | No | If true, the gift pauses for buyer review before printing instead of printing automatically. | |
| shared_payment_token | No | Single-use Stripe Shared Payment Token (spt_...) to pay without a stored card. Omit to charge the account default. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states that the tool charges the buyer, is idempotent for 24 hours, and offers payment options. It omits the preview_before_print behavior, but covers critical billing and idempotency.
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 fluff, efficiently conveying core action, billing, and idempotency. The use of all-caps 'CHARGES' draws attention. Slightly dense but effective.
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 schema coverage and no output schema, the description covers essential behavioral context (billing, idempotency, recipient self-referencing). It does not mention the preview flag or return value, but is otherwise complete for a creation 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 each parameter is already well-documented. The description adds minimal extra context beyond highlighting shared_payment_token and idempotency_key usage. 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 core action: 'Place the order: write, print, and mail the booklet.' It uses specific verbs and resources, and distinguishes from sibling tools like cancel_gift or get_gift by being the creation 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 explains when to use the tool (to order a booklet) and provides payment guidance (pass shared_payment_token or omit). It does not explicitly state to avoid using it for cancellations or lookups, but context from siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_setup_linkAInspect
Return a hosted Stripe link for the buyer to save a card or wallet to the account. After that, create_gift without a shared_payment_token charges the saved card.
| Name | Required | Description | Default |
|---|---|---|---|
| return_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a Stripe link and implies no destructive side effects. However, it lacks details like auth requirements, whether a setup intent is created, or rate limits.
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, front-loaded with the primary action, and contains no extra words. Every sentence contributes 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 no output schema and 0% parameter coverage, the description should compensate. It explains the purpose but omits details about the return_url parameter, response format, or error conditions, leaving the agent underinformed for correct invocation.
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 only parameter (return_url) has no schema description (0% coverage) and the description does not mention it at all, adding no 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 explicitly states the tool's purpose: 'Return a hosted Stripe link for the buyer to save a card or wallet to the account.' It uses a specific verb and resource, and distinguishes its role from siblings by noting a follow-up workflow with create_gift.
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 gives clear usage context: it is used to set up a payment method before creating a gift without a token. However, it does not explicitly state when not to use this tool or compare it to alternatives like cancel_gift or list_gifts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountAInspect
Return this account's spending caps and month-to-date spend. Free. Use it to confirm budget before create_gift.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a free, read-only operation that returns specific data. No contradictions or omissions.
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: first states the function, second adds usage guidance. Extremely concise and front-loaded with essential information.
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 is simple with no parameters and no output schema. The description fully explains what it returns and when to use it, making it complete for an AI agent.
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?
No parameters exist, so the description adds no param info, but the baseline for 0 parameters is 4. Schema coverage is 100% (vacuously), so no compensation needed.
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 returns spending caps and month-to-date spend. It uses a specific verb ('Return') and resource, and the purpose is distinct from sibling tools that deal with gifts, pricing, etc.
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 says to use it to confirm budget before create_gift, providing clear context. It does not mention alternatives or when not to use, but for a simple read-only tool, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_giftAInspect
Fetch a gift by gift_id and return its full resource: status, voice, format, pricing, the recipient, and fulfillment (Lulu job id, carrier, tracking URL, estimated delivery). Free and read-only. Use it to poll progress after create_gift: status advances through the pipeline to shipped then delivered, or ends at held, refused, cancelled, or failed.
| Name | Required | Description | Default |
|---|---|---|---|
| gift_id | Yes | The gift_id returned by create_gift, identifying the order to fetch. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently declares the tool as 'Free and read-only' and explains the status lifecycle (shipped, delivered, held, etc.). This gives the agent sufficient understanding of behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and return fields in the first sentence. Every phrase serves a purpose, with no redundant or irrelevant information.
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?
Despite having no output schema, the description comprehensively lists return fields and the status progression, making it complete for a simple fetch tool. The polling hint further enhances usability.
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 describes the gift_id parameter, but the description adds value by specifying that it is 'returned by create_gift', clarifying its origin. This extra context aids correct usage.
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 'Fetch' and the resource 'gift by gift_id', and enumerates the returned fields (status, voice, format, etc.). It distinguishes from siblings like create_gift and cancel_gift by focusing on retrieval and polling, though it does not explicitly contrast with list_gifts.
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 explicitly advises using this tool to poll progress after create_gift, providing clear context. It also notes the tool is free and read-only. However, it does not mention situations where it should not be used or list alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspect
Compute the exact total for a hypothetical gift (format, voice, image model, ship_to) before you commit. Free, no order is created. Call before create_gift so you know the charge.
| Name | Required | Description | Default |
|---|---|---|---|
| voice | No | Optional comedic voice. It does not change the price; accepted for parity with create_gift. | |
| format | No | Booklet format to price. Only manual_v1 is supported today. | |
| ship_to | Yes | Destination address. US is supported; the total and tax depend on the destination. | |
| image_model | No | Optional cover image model id. Some models add a small per-call cost. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses behavior: it is free, does not create an order, and computes an exact total. It also mentions that image_model may add per-call cost. It could mention idempotency or rate limits, but overall transparent.
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, no wasted words. Efficient and to the point.
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 purpose and usage context, and mentions US support and dependency on destination. However, it does not explain the return value format, which could be helpful given no output schema.
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 has 100% coverage with detailed descriptions for all parameters. The description text does not add additional meaning beyond what the schema provides, so baseline score of 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 computes the exact total for a hypothetical gift before committing. It specifies the verb 'compute' and the resource 'total for a hypothetical gift', and distinguishes itself from create_gift by noting it doesn't create an order.
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 explicitly advises to call before create_gift, implying when to use it. It indirectly contrasts with create_gift by stating no order is created. However, it does not explicitly list when not to use or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_formatsAInspect
List supported booklet formats. There is one today: manual_v1, a 16-page booklet. Free, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full weight. It states 'Free, no side effects,' indicating a read-only operation, which is helpful. Could add more about stability or updates.
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 concise sentences, front-loaded with the 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?
For a tool with no parameters and no output schema, the description is fully self-contained: it describes purpose, current content, and safety profile.
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?
No parameters, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline for 0 params is 4.
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 lists supported booklet formats and provides a specific example (manual_v1), making it distinct from sibling tools which focus on gifts, images, etc.
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 mentions the tool is free and has no side effects, implying it can be used freely. However, it doesn't explicitly compare with alternatives or specify 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.
list_giftsBInspect
Paginated list of gifts on the account, with optional status and date filters. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of gifts to return, 1 to 100. Defaults to 50. | |
| since | No | Only return gifts created at or after this ISO 8601 timestamp. | |
| cursor | No | Opaque pagination cursor from a previous list_gifts response. | |
| status | No | Only return gifts in this status, for example shipped, delivered, or cancelled. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only mentions 'Free' and 'Paginated', lacking details on rate limits, authentication, or data freshness.
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?
Very concise single sentence, front-loading key information; 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?
No output schema and description omits return structure (e.g., fields per gift, pagination metadata), leaving gaps for a list 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 covers all 4 parameters with descriptions; description adds context of pagination and optional filters, but not much beyond 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 specifies a paginated list of gifts with optional filters, clearly distinguishing from other tools like get_gift or create_gift.
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?
Implied usage for listing gifts with filters, but no explicit guidance on when to use versus alternatives like get_gift for a single gift.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_image_modelsAInspect
List supported cover image models and their per-call cost. Free, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'Free, no side effects,' which covers cost and safety. However, it does not specify whether the list is paginated, the exact format of returned data, or if there are any limits. This is adequate for a zero-parameter tool but could be more comprehensive.
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 short sentences that immediately convey the tool's purpose and key behavioral traits (free, no side effects). Every word earns its place, and there is no unnecessary 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 the tool's low complexity (no parameters, no output schema, no annotations), the description covers the essential aspects: what it lists and its cost/safety. It does not describe the return format, but for a list tool, the purpose is clear and sufficient for correct invocation.
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 tool has no parameters, and the schema coverage is 100% (empty). The description does not need to add parameter information, as none exist. The baseline score of 4 applies because the description does not repeat what's already 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 states the action ('List'), the resource ('supported cover image models'), and what's included ('their per-call cost'). It distinguishes itself from sibling tools like list_voices and list_formats by specifying its unique focus.
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 indicates this tool is free and has no side effects, implying safe use at any time. However, it does not explicitly state when to use it versus alternatives or provide when-not conditions, but for a simple list tool, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recipientsAInspect
Return the account's saved recipients (address book). Free. Reuse a recipient_id in create_gift instead of re-entering an address.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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 'Free.' and implies a read operation, but does not disclose potential behavioral traits like rate limits or idempotency. The description is adequate but lacks depth.
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 the main action, and every sentence adds value. 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?
Given no parameters and no output schema, the description sufficiently explains the tool's purpose and usage. It could optionally mention return format, but it is not required for completeness.
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 zero parameters with 100% coverage, so the description does not need to add parameter details. Baseline for 0 params is 4, and the description correctly does not repeat schema info.
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 'Return the account's saved recipients (address book)' which specifies the verb (return) and resource (saved recipients), and distinguishes from siblings by mentioning reuse in create_gift.
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 explicitly says 'Free. Reuse a recipient_id in create_gift instead of re-entering an address.' This provides clear guidance on when to use the tool and its benefit, though it does not include explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_voicesAInspect
List the three comedic voices (Hype Man, Best Friend Roast, Conspiracy Theorist) and the cover image model each prefers. Free, no side effects. Call this first to pick a voice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively carries behavioral disclosure. It states the operation is read-only ('no side effects') and free, and specifies the output content. Given the tool's simplicity (no parameters, no complexity), this transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no unnecessary words. Key information (what is listed, guidance to call first) 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?
For a simple listing tool with no output schema, the description fully explains what it returns (list of three voices and their cover model preferences) and its purpose (pick a voice). No gaps remain given the tool's simplicity.
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 tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter information, but baseline for 0 params is 4, and there is no need for further elaboration.
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 lists three specific comedic voices and their preferred cover image models. It explicitly names the voices, providing exact enumeration, and distinguishes itself by focusing on voice selection, unlike sibling tools like list_formats or list_image_models.
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 advises 'Call this first to pick a voice,' establishing a clear usage order. While it doesn't explicitly exclude scenarios or name alternatives, it implies this tool is the prerequisite for voice-dependent operations, which is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_briefAInspect
Run the content policy on a brief without charging or ordering. Free. Call before create_gift so a refusal surfaces early. A booklet that would wound the recipient is refused here, not at charge time.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | The same brief you would pass to create_gift. It is checked against the content policy, free, with no order created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It states the tool is free, does not charge or order, and that a refusal surfaces early. However, it does not describe the return value or idempotency, leaving gaps for an agent.
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 concise sentences. Each sentence adds unique value: purpose, cost, and usage context. No fluff, 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?
The description lacks details about the output (e.g., success/refusal format) and does not compensate for the absence of an output schema. The nested object parameter is partially explained, but the agent needs more to fully understand the tool's behavior.
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?
There is one parameter 'brief' with a description explaining it is the same brief used for create_gift, which adds contextual meaning beyond the schema. Schema coverage is 100% for the top-level parameter, but inner properties lack 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 validates a brief against content policy without charging or ordering, distinguishing it from create_gift. It uses a specific verb-resource combination and directly aids in sibling differentiation.
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 explicitly says to call before create_gift to surface refusals early, providing clear when-to-use guidance. It does not cover when not to use or mention alternatives, but the context from sibling tools partially compensates.
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!