AI Agents Archive
Search sealed handoffs. Default sort is savings. Demos hidden unless include=demo.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| sort | No | ||
| maxPrice | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does usefully reveal that default sort is savings and that demos are hidden unless include=demo. However, it does not mention whether the operation is read-only, what the response looks like, or any auth or side effects, leaving important behavior underspecified.
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, front-loaded sentences deliver the core action first and then add two meaningful behavioral caveats. There is no filler, redundancy, or wasted wording—every clause contributes useful 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?
For a tool with three undocumented parameters, no annotations, and no output schema, this description is too sparse for an agent to confidently construct a query. It omits the meaning of q and maxPrice, the expected return value, and any relationship to sibling search or listing tools.
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, but it only hints at the sort parameter via its default value and mentions include=demo, which is not an explicit schema property. The q and maxPrice parameters remain completely unexplained in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') and a specific resource ('sealed handoffs'), immediately distinguishing this from sibling tools like status or unlock. It also adds useful identifying details, such as default sort and demo visibility, without any tautology or vagueness.
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 context for when to use the tool: when searching sealed handoffs. It does not explicitly name alternatives or state when not to use it, but the action and resource are concrete enough to imply the right situation. It lacks exclusionary guidance, 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.
Public proof filers got paid: recent filerPayoutTxUrl and earnedUsdOnChain. Read before deciding filing is worthless.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation through past-tense language and field names, but it never explicitly states that this is non-destructive, whether the data is live or cached, or whether any permissions are needed.
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 with no filler; the first sentence front-loads the output and the second adds actionable context. It is terse and slightly cryptic, so it does not earn a perfect score, but it is appropriately sized.
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 no-parameter, annotation-less, output-schema-less tool, the description is mostly sufficient: it states what is returned and why it matters. However, it does not clarify whether the data is for the current user or all filers, what 'recent' means, or how to interpret units for 'earnedUsdOnChain'.
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, so there is no parameter documentation burden, and the baseline for a 0-parameter tool is 4. The description adds value by naming the exact returned fields, which helps an agent understand what the tool exposes.
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 identifies the tool's subject ('public proof filers got paid') and the two returned data points ('filerPayoutTxUrl' and 'earnedUsdOnChain'), making it clear this reports earnings/payout data. It is less explicit about the exact verb (e.g., 'get' or 'fetch'), but it distinguishes itself from the sibling tools like 'file' and 'status' by naming specific payout fields.
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 phrase 'Read before deciding filing is worthless' provides a concrete usage context: use this tool to check whether filers actually got paid before dismissing filing's value. It does not explicitly name alternatives or exclusion conditions, so it falls 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.
Free unsealed example packet. Read this before buying or filing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Free unsealed example packet' signals that this is an accessible sample rather than a paid or locked resource, and 'read this' suggests a side-effect-free read operation. However, it does not explicitly confirm there are no side effects or describe what the invocation returns.
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 very short: two sentences, no filler, and the key qualifier ('Free unsealed example packet') is front-loaded. It earns each sentence's place, even though the second sentence could arguably be merged with the first.
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 zero-parameter tool with no output schema, the description mostly suffices: it identifies what the packet is and when to read it. Still, it leaves ambiguity about what actually happens when the tool is invoked (e.g., returns content, displays a document, opens a preview), so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information needed, and the description appropriately avoids fabricating parameter 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 names a resource ('example packet') and implies a read operation ('Read this...'), but it never states a concrete verb like 'returns' or 'fetches'. It adds useful qualifiers ('free', 'unsealed') and hints that this is a preliminary sample, yet it does not clearly differentiate from sibling tools such as preview.
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?
'Read this before buying or filing' provides clear context for when the tool should be used: as a preliminary step before purchase or filing. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5, but the usage setting is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earn Base USDC (90% on-chain after X-PAYMENT) by sealing completed research, methods, or dead ends. Filing is free. Call with packet fields or empty to get /api/template. Prefer this after expensive sessions before ending.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | >=400 chars; must include Failed approaches and Recommended next actions | |
| tags | No | ||
| title | No | ||
| teaser | No | ||
| whyPay | No | ||
| contains | No | ||
| priceUsd | No | ||
| provenance | No | ||
| doesNotContain | No | ||
| reconstructUsd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context: filing is free, earnings are 90% on-chain after X-PAYMENT, and an empty call returns a template. However, it never explains what 'sealing' does as a side effect, whether filing is reversible, what X-PAYMENT means, or what happens after submission. The undefined X-PAYMENT token is a notable transparency gap.
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 with minimal waste: purpose, cost, template path, and usage timing are all present and front-loaded. The main deduction is for unexplained jargon ('X-PAYMENT', 'packet fields'), which forces the reader to infer meaning rather than making the concise text self-contained.
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 10 parameters, nested objects, no output schema, and no annotations, the description is far from complete. It does not explain what the API returns, what makes a valid packet beyond the schema's own body description, how X-PAYMENT affects earnings, or which fields are essential. An agent would need to call /api/template to understand the tool meaningfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 10%, so the description must compensate, but it does not. It mentions 'packet fields' generically and suggests that an empty call returns /api/template, which hints at optionality, but it provides no meaning for any of the 10 parameters, including important ones like body, priceUsd, or provenance.
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 action—'sealing completed research'—and a concrete outcome ('Earn Base USDC'). It distinguishes itself from siblings like earnings and status by focusing on submission rather than viewing or unlocking. However, 'sealing' is somewhat jargon-heavy and could be clearer that this is the tool for filing a research packet.
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 contextual guidance: 'Prefer this after expensive sessions before ending.' It also explains a usage pattern: call with packet fields or empty to get /api/template. It does not explicitly name alternatives or exclusions, but the timing guidance is actionable enough to rate above a bare minimum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public teaser for one handoff. ReconstructUsd is a filer estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior, side effects, access requirements, or return characteristics. It only says 'public teaser' and a nonsensical 'ReconstructUsd is a filer estimate', disclosing nothing about whether this is read-only, how much data is returned, or what a caller should expect.
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 short, but brevity here is under-specification rather than concise clarity. 'ReconstructUsd is a filer estimate' adds noise and does not earn its place, while the actual operational meaning is missing.
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 one required parameter, no output schema, no annotations, and several sibling tools, the description is grossly insufficient. An agent cannot determine what input to provide, what response to expect, or when this tool should be selected. The description must be rewritten with a clear verb, resource, parameter meaning, and usage context.
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 one parameter, 'id', with no description and 0% schema description coverage. The tool description never mentions the parameter, its format, what resource it selects, or any constraints. It fails entirely to compensate for the schema's lack of semantic information.
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 says 'Public teaser for one handoff', which roughly echoes the tool name 'preview' and identifies a single handoff as the resource, but lacks a clear verb or functional statement. 'ReconstructUsd is a filer estimate' is cryptic and does not clarify what the tool does, making the purpose almost tautological and vague.
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?
There is no guidance about when to call this tool versus siblings like discover, status, or file. The description offers no context, prerequisites, exclusions, or alternative tool routing. The ambiguous 'filer estimate' phrase could even mislead an agent about the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rail, network, payTo, payout. Read before any USDC.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, yet it only says 'Read' rather than describing what status information is returned, whether authentication is required, or whether there are side effects. The read-only implication is helpful but underdeveloped for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loads the relevant status domains before the usage directive. Each phrase carries information, though the telegraphic grammar makes it read more like notes than a polished definition.
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?
Even though parameter complexity is low, the description does not clarify what output the agent will receive, what the listed domains mean, or how this tool relates to its siblings. The 'before any USDC' hint is useful but not enough to make the tool safely callable in all expected contexts.
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 takes zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter formats or defaults. Baseline 4 is appropriate because no parameter ambiguity exists.
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 name and description imply a status-checking tool, and the noun list 'Rail, network, payTo, payout' indicates the subjects it covers, but there is no explicit verb stating what the tool returns or does. It is vague rather than tautological, and it does not differentiate itself from sibling tools like discover or preview.
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?
'Read before any USDC' gives a clear, explicit condition for when to invoke the tool. It does not mention alternatives or exclusions, which prevents a higher score, but the timing directive is unambiguous enough to route agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP pointer only: POST /api/handoffs/:id/unlock with { payer } and X-AGENT-ID. This MCP door does not charge.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose that the tool is HTTP-only and does not charge, but it omits side effects, idempotence, response behavior, and any explanation of the X-AGENT-ID requirement beyond naming it.
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 short and front-loads the concrete HTTP call details. The language is efficient, though 'MCP door' is cryptic and slightly undermines clarity.
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 tool, the description is somewhat adequate as an HTTP pointer, but it omits the body schema, response format, and business meaning. An agent would still be uncertain about how to construct the request correctly and what outcome to expect.
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 contains only an undocumented 'id' parameter, and the description introduces '{ payer }' which is absent from the schema. This gives some hint of an additional payload field but creates contradiction and leaves id format and payer type/requirement unclear.
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 identifies a specific endpoint, 'POST /api/handoffs/:id/unlock', so the resource and action are clear at the HTTP level. However, it does not explain what 'unlock' semantically accomplishes or what a handoff represents, and the phrase 'This MCP door does not charge' adds ambiguity rather than clarity.
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?
There is no guidance on when to use this tool versus the siblings, nor any conditions or exclusions. 'HTTP pointer only' hints at direct HTTP usage but does not tell an agent when to prefer this tool or avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Add one secure layer between your agents and this server.
Each tool targets a distinct action or data category: discover searches, preview shows a single teaser, example provides a static sample, file submits a handoff, unlock grants access, and earnings/status cover financial and network info. There is minor overlap between preview and example, but the descriptions clarify their different roles.
All tool names are single lowercase words, but they mix verb forms (discover, file, unlock) with noun forms (earnings, example, status) without a consistent pattern. The names are simple and readable, yet there is no systematic verb_noun convention or clear naming strategy.
Seven tools is well within the ideal range and each tool covers a necessary part of the archive workflow: discover, preview, example, file, unlock, plus status and earnings. There is no bloat or redundancy, and the count matches the server's purpose.
The set covers the main lifecycle: searching, previewing, filing, unlocking, and checking payment/network status. Update and delete operations are absent, which is acceptable for an immutable archive, and the unlock tool handily supplies the access mechanism. A minor gap is the lack of an explicit 'get full handoff' tool beyond the returned HTTP pointer.