Self-serve publisher onboarding for Lulu Ads. 70% CPA, disclosed sponsored field.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 4 of 4 tools scored.
The four tools are largely distinct: create_publisher starts registration, confirm_publisher completes it, verify_integration checks the integration, and get_integration_guide provides documentation. The only mild overlap is that create_publisher and confirm_publisher both relate to registration, but their roles (initiate vs. complete) are clearly delineated in their descriptions.
Three of four tools follow a clear verb_noun pattern (create_publisher, confirm_publisher, verify_integration), while get_integration_guide deviates slightly with a noun-first structure. The inconsistency is minor and all names remain immediately readable and descriptive of their action.
Four tools is on the lean side but reasonable for a focused onboarding/concierge server covering registration, guidance, and verification. It's slightly below the ideal 5-15 range, leaving a bit of room for operations like updating publisher details or checking status, but the scope is coherent.
The core lifecycle from registration to verification is covered (create, confirm, verify), with the integration guide as helpful documentation. However, there are notable gaps: no way to view a publisher's status, resend a verification code, update publisher info, or delete/disable a publisher after the fact. Agents working with existing registrations have dead ends.
confirm_publisherAInspectComplete publisher registration with the emailed 6-digit code. Returns publisher_id, one-time api_key, and a tailored code snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| pending_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return values (publisher_id, api_key, code snippet) but does not discuss error handling, rate limits, or state changes. For a non-destructive confirmation step, this is adequate but not exhaustive.
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 waste. The purpose is front-loaded, and the return values are listed immediately. Perfectly concise for the information provided.
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 an output schema exists, return value details are partially covered. However, parameter semantics are missing, and there is no guidance on prerequisites (e.g., obtaining pending_id from 'create_publisher') or error scenarios. For a 2-param tool with no annotations, more completeness is expected.
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 fails to explain the parameters 'pending_id' and 'code' beyond their names. It does not clarify what 'pending_id' refers to or how the code is validated.
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 ('Complete') and resource ('publisher registration'), and distinguishes itself from siblings like 'create_publisher' by referencing the emailed code and stating return values (publisher_id, api_key, code snippet).
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 clearly indicates this tool is used to complete registration after receiving an emailed code, implying a sequential workflow with 'create_publisher'. However, it does not explicitly state when not to use it or mention alternatives like 'get_integration_guide'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_publisherAInspectStart publisher registration (requires the human's consent — registers their email). Pass server_url (the MCP server's own URL or repo link) when known — it drives the "server URL set" step on the publisher's dashboard, skipping it leaves that step looking incomplete even once real traffic flows. Emails a 6-digit verification code to contact_email; ask the human for the code, then call confirm_publisher(pending_id, code) to receive the API key. This tool does NOT return a publisher_id or api_key — only confirm_publisher does.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| server_url | No | ||
| contact_email | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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. It discloses key behaviors: it registers the human's email, requires consent, emails a 6-digit verification code to contact_email, and does not return a publisher_id/api_key. It also explains the side effect of server_url on the dashboard server URL set step. This is strong behavioral disclosure for a stateful registration flow.
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 dense and well-structured but every sentence earns its place — no filler. It front-loads the core purpose, then covers the optional param behavior, then the follow-up step, then an explicit negative (what it does NOT return). This is appropriately sized for a tool with a multi-step flow.
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 stateful registration tool with no annotations and 3 params at 0% schema coverage, this description is remarkably complete. It explains the workflow, the human-dependency (consent, email code), the follow-up tool call, and the return-value caveat. The output schema exists and the description appropriately leaves return-format details to it.
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 0%, so the description must compensate, and it does. It clarifies the semantics of server_url (drives the server URL set step, pass repo link or MCP URL) and contact_email (receives the verification code). The 'name' parameter is not elaborated, but the main ambiguous ones are well explained, compensating for the zero 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?
Description clearly states this starts publisher registration and that it's a multi-step flow requiring confirmation. The verb 'Start' plus 'publisher registration' gives a clear purpose. It doesn't sharply differentiate from siblings by name, but the explicit mention that it requires human consent and the confirmation step via confirm_publisher distinguishes it functionally.
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?
Excellent usage guidance: it explicitly says to pass server_url when known and explains the consequence of skipping it (dashboard step looks incomplete). It also gives explicit sequencing — ask for the email code, then call confirm_publisher(pending_id, code). It even names the sibling tool confirm_publisher and clarifies that this tool does NOT return publisher_id or api_key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_integration_guideAExact integration guide for a stack: fastmcp | python | typescript | langgraph | crewai | generic | openclaw.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | fastmcp |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description confirms it provides a guide, but no additional behavioral context (e.g., auth needs, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no superfluous content.
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 and an output schema, the description is mostly complete; could mention if guide is a URL or text, but output schema likely covers it.
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?
Description adds allowed values for the 'framework' parameter beyond the schema, which only specifies type and default; schema coverage is 0% so this is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides an exact integration guide for specific stacks, distinguishing it from sibling tools like create_publisher and verify_integration.
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 on when to use or not use this tool versus alternatives; simply lists possible stack values without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_integrationACheck whether this publisher has produced a slot_served event (integration
works). Pass fastmcp_version (e.g. from fastmcp.__version__ or
pip show fastmcp) when the integrated server uses FastMCP — it's recorded
so version-specific failures are traceable, not required to verify.
| Name | Required | Description | Default |
|---|---|---|---|
| publisher_id | Yes | ||
| fastmcp_version | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context about the fastmcp_version purpose ('recorded so version-specific failures are traceable'), which goes beyond the schema. However, the readOnlyHint=true annotation already covers the safety profile, so the added value is moderate. The description doesn't clarify what the return value looks like or what the outcome is when the event hasn't fired, though the presence of an output schema partially mitigates this.
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 a single paragraph with a clear first sentence defining purpose, followed by concise practical guidance on the optional parameter. It's front-loaded with the core function. The parenthetical could arguably be trimmed, but it's genuinely useful and not redundant, so the length is justified.
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 there's an output schema (which presumably documents the verification result), the description covers the essential operational aspects: how to obtain fastmcp_version, when it applies, and that it's optional. The tool is relatively simple (2 params, 1 required), and the description addresses the only non-obvious element (the optional version parameter). The lack of explicit exclusion guidance vs. get_integration_guide is a minor gap but not critical for this straightforward check.
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 of explaining parameters. The description explains fastmcp_version's semantics well (how to obtain it, when to pass it, why it matters). However, publisher_id is only implicitly understood through the description's use of 'this publisher,' and no additional meaning beyond 'a string publisher identifier' is provided. Given zero schema coverage, this is a partial compensation only.
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 what the tool does: 'Check whether this publisher has produced a slot_served event (integration works).' It uses a specific verb (check) with a specific resource (publisher's slot_served event) and explains what success means (integration works). While it's clear on its own, it doesn't explicitly distinguish itself from sibling tools like get_integration_guide or confirm_publisher, so some inference is needed to understand the 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 explains when to include fastmcp_version ('when the integrated server uses FastMCP') and clarifies it's optional ('not required to verify'). This gives clear practical guidance on parameter usage specific to the integration scenario. However, it doesn't explicitly state when NOT to use this tool versus alternatives like get_integration_guide, leaving the alternative-selection guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!