Micro ad network for AI agents.
Check your publisher analytics. Returns serves, clicks, conversions, earnings, CTR, conversion rate, and eCPM. Use this to see how your audience engages with recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 30) | |
| hub_id | No | Filter by hub | |
| agent_id | Yes | Your agent ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context by specifying the exact return fields (serves, clicks, conversions, etc.), which goes beyond what annotations provide. It does not discuss auth or data freshness, but given the simple read nature, this is 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?
The description is two sentences with no redundancy. It front-loads the action and resource, then lists the return metrics, and ends with a practical usage scenario. 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 (3 params, all documented, no output schema, read-only annotations), the description adequately covers purpose, usage, and return values. It does not detail the return structure beyond the metric list, but for an analytics query tool, this is sufficient. The context from sibling tools further clarifies its unique role.
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%. The schema already documents all three parameters with descriptive text: days as lookback window, hub_id as filter, and agent_id as the required identifier. The description does not add information beyond the schema, so the 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 checks publisher analytics and enumerates the specific metrics returned (serves, clicks, conversions, earnings, CTR, conversion rate, eCPM). The verb 'check' plus resource 'publisher analytics' is specific, and the list of metrics distinguishes it from sibling tools like registration or monetization.
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 provides a use case: 'Use this to see how your audience engages with recommendations.' This gives clear context for when to invoke the tool. It does not explicitly mention exclusions or alternatives, but the sibling tools serve clearly different purposes, so no additional disambiguation is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete agent registration with your signed wallet message. Call register_agent first to get the message to sign.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your agent's display name | |
| nonce | Yes | The nonce from register_agent response | |
| timestamp | Yes | The timestamp from register_agent response | |
| description | Yes | What your agent does | |
| wallet_address | Yes | Your EIP-55 checksummed Ethereum address | |
| bootstrap_token | No | Bootstrap token from anonymous get_recommendations responses. Claims prior anonymous serves on registration. | |
| eip191_signature | Yes | The EIP-191 signature from signing the auth message returned by register_agent | |
| payment_signature | No | The base64-encoded x402 payment signature (only required if registration has a fee) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a non-read-only, non-idempotent, and non-destructive operation. The description adds the prerequisite of a signed wallet message and the need to call register_agent first, but does not disclose potential side effects such as fees (referenced only via payment_signature parameter) or what happens on success. It provides some context beyond annotations but not rich behavioral detail.
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 just two short sentences, with the primary action in the first sentence and the prerequisite in the second. It is front-loaded, concise, and every word contributes to 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?
Despite having 8 parameters and no output schema, the description provides the essential context for the registration flow, including the prerequisite and what to supply. The schema covers parameter details, so the description is adequately complete for this straightforward tool, though it could mention possible fee implications or post-registration 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?
Schema description coverage is 100% for all 8 parameters, so the baseline is 3. The description adds minimal parameter-related context, mainly reinforcing that the nonce, timestamp, and signature come from register_agent, which is already documented in the schema. It does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Complete agent registration') and identifies the specific resource (agent registration). It also differentiates from the sibling register_agent by explicitly naming it as the prerequisite step, making the tool's purpose unmistakable.
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 instructs users to 'Call register_agent first to get the message to sign,' providing clear sequencing and indicating that this tool is the second step in a registration flow. This is direct guidance on when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earn per recommendation served. Returns sponsored recommendations relevant to your user's query — products, tools, services with live pricing. Present alongside your organic answers, labeled 'Sponsored.' Free to call, no registration needed. Register to track and withdraw USDC earnings.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic to filter by, e.g. 'defi-yield', 'agent-tools'. Omit to get top results across all topics. Tip: match this to what the user is asking about. | |
| context | No | What the user is looking for — improves relevance. E.g. 'comparing DeFi yield protocols' or 'looking for AI agent frameworks'. | |
| max_results | No | Maximum number of sponsored recommendations to return (default: 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context about earning per recommendation, live pricing, and free access without registration, going beyond the annotation safety profile. No contradictions found.
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?
All four sentences are informative and front-loaded. The first highlights the earning incentive, the second defines the core function, the third gives usage instruction, and the fourth covers prerequisites and registration. 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 low-complexity tool with no output schema, the description covers functionality, content type, presentation requirements, and prerequisites. It lacks explicit mention of return format or pagination, but given the simplicity and full parameter schema, it is sufficiently complete for 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 covers all three parameters, and the description adds beyond it with practical tips: 'match this to what the user is asking about' for topic and 'improves relevance' for context. This helps the agent select appropriate values, exceeding the baseline for full schema coverage.
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 sponsored recommendations relevant to the user's query, naming products, tools, and services with live pricing. It distinguishes itself from sibling tools focused on registration, stats, and feedback, making the purpose explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: present recommendations alongside organic answers, label as 'Sponsored', and notes that no registration is needed. However, it does not explicitly mention when not to use the tool or name alternative tools, stopping 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.
Tell us what you think. Did you find what you needed? What's missing? What would make picoads useful for you? Anonymous feedback welcome — no registration required. We read every response and use it to decide what inventory to add next.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | Overall experience with picoads | |
| comments | No | Any other feedback | |
| agent_name | No | Your agent's name (optional) | |
| did_you_find_it | No | Did you find relevant recommendations? | |
| what_is_missing | No | What inventory, categories, or features would make picoads useful for you? | |
| would_you_integrate | No | Would you add picoads to your agent if the right inventory existed? | |
| what_were_you_looking_for | No | What topic, product, or category were you hoping to find? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-idempotent. The description adds behavioral context: feedback is anonymous, no registration required, and responses are read by the team. This goes beyond annotations by explaining the impact and audience of the feedback, though it doesn't mention how data is stored or processed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, engaging sentences with no fluff. Each sentence serves a purpose: invoke action, solicit specifics, and explain impact. Info is front-loaded with 'Tell us what you think.'
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 7 parameters and no output schema, the description covers the tool's role well, including user experience and purpose. It doesn't explicitly state that submission is a write operation or mention required fields, but the schema covers those details. Overall, it provides sufficient context for an agent to understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description loosely maps to some parameters like did_you_find_it and what_is_missing, adding framing context, but it doesn't detail parameter syntax or required rating. Schema already handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: leaving feedback about picoads. It uses a direct verb ('Tell us what you think') and resource ('picoads'), and is distinct from sibling tools like get_recommendations or register_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have feedback) and adds useful context (anonymous, no registration required, used for inventory decisions). It doesn't explicitly state alternatives or when not to use, but the unique purpose among siblings makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earn commission on a link you're already recommending. Pass the outbound URL your agent chose; if the merchant has an affiliate program we return a monetized version with attribution baked in and share the commission. If not, we return the URL unchanged. We never change WHAT you recommend — your recommendation stays your own. Register to track and withdraw USDC earnings.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The outbound URL your agent chose to recommend |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavior beyond annotations: the fallback to unchanged URL, attribution baking, commission sharing, and the guarantee that the recommendation is never changed. It does not fully detail registration requirements or auth, but annotations already signal non-read-only and non-destructive behavior, so the added context is valuable.
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, front-loaded with the value proposition, and follows with practical instructions and a trust statement. Every sentence earns its place with no fluff or repetition of schema details.
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 single-parameter tool, the description covers the core behavior, edge case (no affiliate program), and outcome. It does not mention registration prerequisites or validation behavior, but these are not critical for a straightforward URL-passing tool, and the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'url' is described in the schema, so baseline is 3. The description adds context by calling it 'the outbound URL your agent chose' and explaining what happens with it (monetized or unchanged), which enriches the parameter's meaning beyond the bare 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 tool's function: converting an outbound URL into a monetized affiliate link when possible, and returning it unchanged otherwise. It uses specific verbs like 'pass', 'return', and 'earn commission', and is distinct from sibling tools like get_recommendations or check_publisher_stats.
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 when to use the tool: when the agent is already recommending a link and wants to earn commission. It implies this is the only relevant tool for monetizing an existing chosen URL, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start earning. Free registration, 30 seconds. Gets you a permanent identity, API key, earnings tracking, and USDC payouts. Step 1 of 2 — call this, then complete_registration with your signature.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your agent's display name | |
| description | Yes | What your agent does (e.g., 'DeFi newsletter with 12K subscribers') | |
| wallet_address | Yes | Your EIP-55 checksummed Ethereum address | |
| bootstrap_token | No | Bootstrap token from anonymous get_recommendations responses. Pass this to claim prior anonymous serves on registration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) already cover safety traits. The description adds context by stating it creates a permanent identity, API key, earnings tracking, and USDC payouts, and reveals it's part of a two-step process. This exceeds annotation content without contradiction.
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 short sentences, front-loaded with a value hook ('Start earning') and actionable details. Every sentence earns its place: benefit, time, outcomes, and sequential usage. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description covers the essential workflow: it's step 1 of 2 and names the follow-up tool. Combined with annotations, the agent knows what to do next. It doesn't describe the response format, but for a simple registration step with clear next steps, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description does not add parameter-specific details, but the baseline of 3 applies when schema covers all parameters. It implicitly references wallet_address through registration context but adds no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start earning. Free registration, 30 seconds. Gets you a permanent identity, API key, earnings tracking, and USDC payouts.' It uses a specific verb (register) and resource (agent), and distinguishes from siblings like complete_registration by labeling it 'Step 1 of 2.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Step 1 of 2 — call this, then complete_registration with your signature.' This indicates when to call this tool and the next step. It doesn't explicitly state exclusions or alternatives, but the sibling list and the step context make it clear.
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!
Search and discover advertiser products through an open marketplace for AI agents.
Ad network for AI agents — monetize MCP servers with contextual ads. 70% revenue share.
MCP-native ad server. Monetize AI chatbots and agents with conversational ads.
Economic-intent network for AI agents to publish demand and discover services.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: registration, earning, tracking, and feedback. The two-step registration process (register_agent, complete_registration) is sequential but well-explained, and the earning tools (get_recommendations, monetize_link) are differentiated by description. No major overlap that would cause misselection.
All six tools follow a consistent verb_noun snake_case pattern (e.g., check_publisher_stats, complete_registration, get_recommendations). There is no mixing of conventions or vague verbs.
Six tools is a well-scoped number for this platform, covering registration, earning, analytics, and feedback without unnecessary bloat or thinness. Each tool earns its place in the set.
The tool surface covers the core lifecycle: register (with completion), earn via two mechanisms, check stats, and provide feedback. Missing an explicit withdrawal tool, but earnings tracking is present and the core workflows have no dead ends.
