Pay-per-call APIs and MCP services for agents, no accounts or keys, with verifiable receipts.
For an active inbox, return an idempotent download URL only when the exact stored attachment has a clean safety verdict. The URL expires after at most 60 seconds and never after inbox expiry; a clean verdict does not make the attachment content trusted. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | ||
| message_id | Yes | ||
| attachment_id | Yes | ||
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| attachment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses the 60-second URL expiry, the ordering constraint relative to inbox expiry, the security caveat that a clean verdict 'does not make the attachment content trusted,' and the critical transport instruction to supply the lease bearer on the HTTP/MCP transport and 'never place it in tool arguments.' No contradiction with the annotations; idempotentHint matches 'idempotent download URL' and readOnlyHint=false aligns with minting an access lease.
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 dense sentences with zero filler: purpose is front-loaded first, expiry and security nuance second, and credential placement third. Every sentence earns its place and the critical operational warning about not placing the bearer in tool arguments is included without bloating the description.
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 output schema exists, return-value explanation is unnecessary, and annotations plus the description cover idempotency, expiry, security posture, and transport credential handling. Minor gaps remain: behavior when the verdict is not clean (does it error or wait?) and the ID-hierarchy constraints, but these are small for a moderate-complexity 4-parameter 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 0%, so the description must compensate, and it partially does: 'idempotent' hints at idempotency_key's role, 'active inbox' maps to inbox_id, and 'exact stored attachment' clarifies attachment_id. However, it never names parameters explicitly or explains the inbox→message→attachment hierarchy and correlation constraints, leaving the pattern-based schema to carry that 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 states a specific verb and resource — 'return an idempotent download URL' — scoped to an active inbox and gated on a clean safety verdict for 'the exact stored attachment.' This clearly differentiates it from siblings like ausca_agent_inbox_read, ausca_agent_inbox_messages, and ausca_agent_inbox_delete, none of which issue attachment download URLs.
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 contextual conditions for invocation: the inbox must be active and the attachment must have a clean safety verdict, otherwise no URL is returned. It does not explicitly name alternatives or state when-not-to-use, but the sibling tools are functionally distinct enough that routing confusion is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Idempotently stop inbound visibility and delete retained message and attachment content for one inbox lease, including an already-terminal lease. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes |
| Name | Required | Description |
|---|---|---|
| inbox | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint and idempotentHint, but the description adds substantial detail: exactly what gets destroyed (retained message and attachment content), the effect of stopping inbound visibility, and the edge case of already-terminal leases. The bearer-transport instruction is additional behavioral context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary effect is front-loaded, then the idempotency/edge case, then the auth instruction. Every clause 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?
For a single-parameter delete tool with output schema present and annotations covering safety, the description is complete: purpose, scope of deletion, idempotency, terminal-lease handling, and transport/auth requirements. Nothing an agent needs to invoke correctly is missing.
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 0%, so the description must compensate. It ties the single inbox_id parameter to 'one inbox lease' and clarifies that the lease bearer should not be passed as an argument, which informs parameter usage. However, it does not elaborate on how to obtain the id or interpret the pattern beyond what the schema already provides.
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 states a specific verb and resource: it idempotently stops inbound visibility and deletes retained message/attachment content for one inbox lease. This clearly distinguishes it from sibling tools like ausca_agent_inbox_read, ausca_agent_inbox_status, and ausca_agent_inbox_messages, which observe or retrieve rather than destroy.
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 context: it can be used on an already-terminal lease and is idempotent. It also gives a practical transport guideline (supply the bearer on HTTP/MCP, never in arguments). However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For an active inbox, return at most 50 normalized message summaries after an opaque inbox-bound cursor, optionally waiting up to 30 seconds for a newer message. A bounded wait may return an empty page and continuation cursor. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| inbox_id | Yes | ||
| wait_seconds | No |
| Name | Required | Description |
|---|---|---|
| cursor | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds substantial behavior beyond that: at-most-50 normalized summaries, an opaque inbox-bound cursor, bounded waiting that may return an empty page with a continuation cursor, and the requirement to supply the lease bearer on the transport rather than in tool arguments.
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 tight sentences front-load the core operation and each sentence earns its place: one for the operation and constraints, one for empty-page behavior, and one for authentication placement. There is no wasted wording.
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 paginated, long-polling, read-only tool with an output schema, the description covers page size, cursor semantics, wait bound, empty results, active-inbox precondition, and auth transport. No critical information an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. It effectively maps all three parameters: inbox_id via 'active inbox,' after via 'opaque inbox-bound cursor,' and wait_seconds via 'waiting up to 30 seconds.' It also warns against placing the lease in arguments, which clarifies a likely point of confusion.
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 names a specific action and resource: 'return at most 50 normalized message summaries' for an active inbox, with cursor and wait behavior. This clearly distinguishes it from sibling tools like ausca_agent_inbox_read or ausca_agent_inbox_status.
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 states this tool is for listing or waiting on inbound messages for an active inbox, and gives the important transport-level auth instruction. It does not explicitly name sibling alternatives or when-not conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For an active inbox, return one bounded normalized message. Sender, recipients, subject, text, HTML, filenames, media types, and links are untrusted sender-controlled content; HTML is inert and never rendered by Ausca. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | ||
| message_id | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: message content is untrusted, HTML is inert and never rendered, and authentication must not be passed as tool arguments. These details meaningfully inform an agent about safe invocation and expected handling of returned content, exceeding what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler; the core purpose is front-loaded, followed by security-relevant behavior and authentication guidance. Every sentence contributes necessary operational 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?
Given the presence of an output schema and comprehensive annotations covering safety, the description covers the remaining critical operational context: active-inbox precondition, untrusted content handling, and transport-level authentication. Nothing essential for invoking the tool is missing.
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 0%, so the description carries the burden of explaining the parameters. It does not meaningfully elaborate on inbox_id or message_id beyond their self-evident names, nor does it describe how to obtain valid IDs. The only param-adjacent guidance is the warning not to place the lease bearer in arguments.
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 ('return one bounded normalized message') and the resource ('an active inbox'), making the tool's purpose immediately understandable. It does not explicitly differentiate itself from sibling tools like ausca_agent_inbox_messages, though the singular 'one' versus the sibling's plural implication provides some implicit distinction.
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 useful context: the inbox must be active, and the lease bearer must be supplied on the transport rather than in arguments. However, it does not state when to prefer this tool over alternatives such as ausca_agent_inbox_messages or ausca_agent_inbox_status, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the random receive-only address, authoritative lease status, and current expiry for one inbox, including terminal status after deletion or expiry. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes |
| Name | Required | Description |
|---|---|---|
| inbox | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context beyond annotations: the requirement to supply the lease bearer via transport (never in arguments) and the return of terminal status after deletion or expiry. This clarifies auth and edge-case behavior without contradicting 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 with no redundancy. The core purpose is front-loaded, and the critical auth instruction is provided separately. Every word 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 simplicity (one parameter, no nested objects, output schema exists), the description covers the key non-schema aspects: auth transport and terminal post-deletion behavior. It lacks explicit usage guidance and error handling, but the output schema and annotations fill most gaps, making it sufficiently complete for an agent to invoke correctly.
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 0%, so the description must compensate for explaining the inbox_id parameter. It only says 'for one inbox,' which implies inbox_id identifies the inbox but does not clarify its format, origin, or constraints. No extra semantic value is provided beyond what the schema pattern already shows, leaving the agent with minimal guidance.
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 concrete verb-resource pair (return address, lease status, expiry for one inbox) and adds a distinguishing detail (terminal status after deletion/expiry) that sets it apart from sibling tools like ausca_agent_inbox_read or ausca_agent_inbox_delete. An agent can tell this is a status query, not a message fetch or mutation.
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 states what the tool does but gives no explicit guidance on when to use it versus siblings (e.g., ausca_agent_inbox_read or ausca_agent_inbox_delete). It does not mention prerequisites, alternative selection criteria, or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Idempotently terminate the CDP relay and upstream browser for one lease. Closing never creates another payment. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| session | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' destructive and idempotent hints, the description states what is destroyed (CDP relay and upstream browser), adds a critical side-effect guarantee ('Closing never creates another payment'), and explains that the lease bearer belongs on transport, not in tool arguments. No statement contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the action and add only high-value behavioral and security context. No sentence is redundant with the title or schema.
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 one-parameter, clearly annotated close action with an output schema, the description plus annotations cover the essential behavior, side effects, and auth placement. Minor gaps remain around error behavior and where the session_id comes from, but these are not blocking.
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, session_id, has no property description in the schema, and the description never explicitly explains that session_id is the lease identifier or how to obtain it. It does add one valuable semantic warning—do not place the lease bearer in tool arguments—which prevents a common misuse. With 0% schema coverage, this partial compensation is useful but incomplete.
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 action ('terminate') and names the exact resources affected ('CDP relay and upstream browser'), scoped to 'one lease.' This makes it unambiguous and easily distinguishable from the connect and status siblings, which create/attach or inspect sessions.
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 implies the tool is for ending an existing lease and is safe to call repeatedly ('idempotently'), and it gives concrete transport-level instructions for supplying the lease bearer. It does not explicitly name alternatives or when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one single-use Ausca CDP relay URL for a ready lease. The URL expires after 60 seconds, only one CDP connection may be live, and no more than eight tickets may be issued per lease. Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments. The upstream provider URL and credential are never disclosed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| connection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals concrete behavioral traits: 60-second expiry, only one live CDP connection, up to eight tickets per lease, and no disclosure of upstream credentials. These details give the agent a much richer operational model than the annotations alone.
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 dense sentences with the core purpose front-loaded, followed only by operationally relevant constraints and security guidance. Every sentence earns its place; there is no filler or 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?
The description thoroughly covers purpose, readiness conditions, limits, auth handling, and secrecy. However, it leaves the required parameters completely undocumented in both the schema and description, so an agent must infer what session_id and idempotency_key represent in relation to the lease.
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 0%, yet the description never mentions session_id or idempotency_key, nor how they relate to the lease. The regex patterns in the schema provide some format guidance, but the description does not compensate for the missing semantics.
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 states a precise verb and resource: 'Return one single-use Ausca CDP relay URL for a ready lease.' It also adds distinguishing constraints (expiry, one connection, ticket cap) that separate it from sibling tools like ausca_browser_session_close and ausca_browser_session_status.
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 says when the tool applies ('for a ready lease') and gives an explicit usage rule: supply the lease bearer on the transport and never in tool arguments. It does not name alternative tools or exclusion conditions, but the context is sufficient for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return authoritative status and expiry for one browser-session lease. The lease capability is supplied by the transport and is never a tool argument or response field.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| session | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by clarifying that the status is authoritative, that the lease capability is transport-supplied, and that the lease is neither a tool argument nor a response field.
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 with no filler. The primary purpose is front-loaded, and the second sentence earns its place by preventing a common misunderstanding about the transport-level lease.
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 output schema exists and annotations cover the safety profile, so return values and side effects are mostly handled. However, the description omits usage context and does not explain how to source the session_id, leaving an agent to infer these details.
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, session_id, is not described in the schema or the description. With 0% schema description coverage, the description needed to explain how to obtain or interpret session_id, but it only clarifies what is not an argument rather than what the parameter means.
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 names a specific verb ('Return') and resource ('one browser-session lease') and states the exact outcome ('status and expiry'). This clearly distinguishes it from sibling tools like ausca_browser_session_connect and ausca_browser_session_close.
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 no explicit guidance on when to use this tool versus alternatives such as connect or close. An agent must infer usage from the tool name and read-only annotations rather than from stated conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request bounded cancellation of one invocation. Cancellation is idempotent, may be refused, and may lose a race with terminal completion.
| Name | Required | Description | Default |
|---|---|---|---|
| invocation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and idempotent hints. The description adds valuable nuance by saying cancellation may be refused and may lose a race with terminal completion, which goes beyond the structured annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core operation is front-loaded, and each clause adds meaningful information, making excellent use of limited space.
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?
With one parameter, an output schema, and rich annotations, the description covers the key caveats: idempotency, refusal, and race with terminal completion. It doesn't explain how a refused or lost cancellation is reported, but the output schema likely covers that.
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 single parameter invocation_id has no schema description (0% coverage), but the phrase 'of one invocation' links it to the target of the operation. The description doesn't elaborate on format or constraints, though the parameter name is fairly self-explanatory.
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 names the verb ('request bounded cancellation') and resource ('one invocation'), clearly stating the operation. There are no other cancellation siblings, so the lack of explicit differentiation from alternatives is acceptable, but it doesn't go out of its way to distinguish itself.
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 is given about when to use this tool instead of alternatives, such as prerequisites or context (e.g., only for in-progress invocations). The behavioral caveats are informative but don't help an agent decide between this tool and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the authoritative durable state, output commitment, and receipt reference for one invocation without creating a new purchase or retry identity.
| Name | Required | Description | Default |
|---|---|---|---|
| invocation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds value by disclosing exactly which state is authoritative and by explicitly ruling out side effects ('without creating a new purchase or retry identity'), which helps an agent understand observable 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?
A single, front-loaded sentence states the verb, object, and key constraint with no redundant wording. Every phrase contributes either to purpose or to side-effect clarification.
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?
With a one-parameter schema, rich annotations, an output schema, and a clear statement of authoritative state contents, nothing essential is missing. The description is appropriately small for the low complexity and does not need to repeat return-value details already present in the 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 schema has no description coverage, so the description must carry semantic weight. It links invocation_id to 'one invocation' but otherwise leaves identifier semantics to the schema's name and pattern, providing only partial compensation for the coverage gap.
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 ('Read'), identifies a precise resource (authoritative durable state, output commitment, receipt reference), and scopes it to a single invocation. The phrase 'without creating a new purchase or retry identity' helps distinguish it from purchase/retry siblings like ausca_prepare_invocation.
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 frames the tool as the read/state-inspection path for a single invocation, which is the context an agent needs to choose it over mutating siblings. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve one active offer or an exact immutable revision, including the schema and revision digests required to construct a valid invocation envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| offer_id | Yes | ||
| revision_digest | No |
| Name | Required | Description |
|---|---|---|
| offer | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive behavior. The description adds meaningful behavioral context beyond annotations by explaining active versus exact immutable revision semantics and noting that the result includes the schema and revision digests needed to build an invocation envelope.
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, front-loaded sentence with no wasted words. It immediately states the core action and then adds the most important related detail about digests and schema.
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 small parameter set, clear annotations, and presence of an output schema, the description covers the essential resolution behavior and why the result matters. It is slightly incomplete only in not routing the agent to sibling tools for discovery or listing.
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 0% schema description coverage, the description needs to compensate, and it partially does: 'active offer' maps to offer_id and 'exact immutable revision' clarifies revision_digest. However, it does not explicitly explain which parameter is required, that revision_digest is optional, or how the two parameters interact when both are present.
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 ('Resolve') and a clear resource ('one active offer or an exact immutable revision'), and it distinguishes the tool from siblings like ausca_search_offers by emphasizing exact single-offer resolution and the revision/schema digests needed for an invocation envelope.
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 does not explicitly name alternatives or state when not to use this tool. It implies use when you need a specific offer or immutable revision with its digests, but it leaves the agent to infer that discovery/search belongs to ausca_search_offers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate one exact invocation envelope and return immutable preparation terms or a typed refusal. Preparation never accepts payment material from model-authored tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| offer_id | Yes | ||
| offer_revision | Yes | ||
| parent_binding | No | ||
| idempotency_key | Yes | ||
| input_schema_digest | Yes | ||
| output_schema_digest | Yes | ||
| canonicalizer_version | Yes | ||
| offer_revision_digest | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds meaningful behavior: results are 'immutable preparation terms', failures are 'typed refusal's, and payment material is categorically rejected from model-authored arguments. These traits are not already disclosed by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint, so the description adds real value without contradicting 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 with no filler. The core purpose and primary safety constraint are front-loaded, and every phrase earns its place. The description is compact while avoiding tautology.
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?
Although the output schema exists and annotations cover safety, the tool has a complex 9-parameter input schema with zero parameter documentation both in the schema and the description. The description also omits when-to-use guidance relative to siblings. For a tool this intricate, the missing parameter semantics make the definition incomplete for reliable 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?
Schema description coverage is 0%, so the description carries full responsibility for explaining the 9 parameters, but it does not. The only parameter-related clue is the payment-material restriction, which implicitly touches the 'input' field. The remaining parameters — offer_id, offer_revision, digests, canonicalizer_version, idempotency_key, parent_binding — receive no semantic explanation, leaving a major gap.
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 states a specific verb ('Validate'), a specific resource ('one exact invocation envelope'), and the outcome ('return immutable preparation terms or a typed refusal'). This clearly distinguishes it from sibling tools like cancel, get, or search, and the payment-material constraint adds further operational specificity.
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 the tool is for validation/preparation of an invocation and warns that payment material must never come from model-authored arguments. However, it never explicitly states when to use this tool versus siblings such as ausca_get_offer or ausca_get_invocation, nor does it name alternatives or exclusion conditions. Usage context is present but inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the current immutable Ausca offer catalog by free-text query. Returns stable offer identities and revision digests without creating product or payment state.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
| offers | Yes | |
| status | Yes | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior, but the description adds valuable behavioral context: the catalog is immutable, no product or payment state is created, and results are stable identities plus revision digests. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the primary action, target resource, and key behavioral guarantee are front-loaded. Every clause 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 rich annotations, the output schema, and the straightforward search operation, the description covers the essential behavioral context. It does not fully document all parameter semantics, but the presence of an output schema and the concise side-effect-free guarantee make the tool adequately callable.
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 0% and the description does not explain q, limit, or cursor. The phrase 'free-text query' implies the meaning of q, but limit and cursor receive no semantic guidance beyond the schema's raw constraints; the description does not compensate for the coverage gap.
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 ('Search') and resource ('current immutable Ausca offer catalog') and specifies the return value ('stable offer identities and revision digests'), which clearly differentiates it from siblings like ausca_get_offer. It is immediately obvious what this tool does and how it is distinct.
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 context for using this as a read-only catalog search, and phrases like 'without creating product or payment state' imply when it is appropriate. However, it does not explicitly name alternatives or state when to prefer ausca_get_offer or ausca_prepare_invocation, so routing guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
ausca_cancel_invocation1 field changedOutput schema / $defs / ReceiptReference / properties / public_urlAdded value: +{
+ "description": "Unguessable public verification page for the privacy-bounded hash-only proof. It reveals the receipt digest, service, public price, and completion time, but not input bytes, output bytes, or their content digests.",
+ "format": "uri",
+ "maxLength": 2048,
+ "pattern": "^https://[^?#]+/r/[a-f0-9]{64}$",
+ "type": "string"
+}ausca_get_invocation1 field changedOutput schema / $defs / ReceiptReference / properties / public_urlAdded value: +{
+ "description": "Unguessable public verification page for the privacy-bounded hash-only proof. It reveals the receipt digest, service, public price, and completion time, but not input bytes, output bytes, or their content digests.",
+ "format": "uri",
+ "maxLength": 2048,
+ "pattern": "^https://[^?#]+/r/[a-f0-9]{64}$",
+ "type": "string"
+}ausca_agent_inbox_messages1 field changedOutput schema / $defs / AgentInboxMessageSummary / properties / received_at / descriptionAdded value: +"Server-observed ingress time. Never derived from the sender-controlled Date header."ausca_agent_inbox_read1 field changedOutput schema / $defs / AgentInboxMessage / properties / received_at / descriptionAdded value: +"Server-observed ingress time. Never derived from the sender-controlled Date header."ausca_agent_inbox_attachmentausca_agent_inbox_deleteausca_agent_inbox_messagesausca_agent_inbox_readausca_agent_inbox_statusausca_browser_session_closeausca_browser_session_connectausca_browser_session_statusausca_cancel_invocationausca_get_invocationausca_get_offerausca_prepare_invocationausca_search_offersClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Pay-per-use APIs for agents: web research, data lookups, and metered endpoints billed to credits.
Add one secure layer between your agents and this server.
Each tool targets a clearly separate operation within its domain: inbox read/list/attachment/status/delete are all distinct, browser connect/status/close are unambiguous, and offer/invocation tools each have unique responsibilities. Descriptions reinforce the boundaries, so an agent should not struggle to select the right tool.
Naming is divided into two patterns: resource-first names like ausca_agent_inbox_read and ausca_browser_session_close, versus verb-first names like ausca_get_invocation and ausca_search_offers. Within the inbox and browser groups, endings mix nouns (messages, status, attachment) and verbs (delete, read, connect), making the convention inconsistent across the set.
13 tools is well within the ideal range for a multi-domain server, and each tool covers a meaningful operation without redundancy. The count supports inbox, browser session, and offer/invocation workflows without feeling bloated or sparse.
The inbox and browser-session clusters cover their core lifecycles well, and the offer/invocation cluster supports search, detail, preparation, state read, and cancellation. The main gap is the lack of an explicit submit/execute invocation tool, though invocation submission may be intentionally externalized; this is a minor workaround rather than a fatal dead end.
