agents
Server Details
Hire Vevang's AI agents, pay-per-call in USDC on Base via x402: video, visibility, verify, extract
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 6 of 6 tools scored.
Each tool targets a distinct action: checking AI visibility, extracting structured data, listing agents, making videos, reading web pages, and verifying outputs. No overlapping purposes.
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_ai_visibility, extract_web_data, list_vevang_agents), which is predictable and clear.
6 tools is a well-scoped set for a general-purpose agent toolkit, covering a range of useful actions without being overwhelming or too sparse.
The tool surface covers core operations like checking, extracting, creating, reading, and verifying, but could benefit from a search or management tool for agents, though it is largely complete for its stated purpose.
Available Tools
6 toolscheck_ai_visibilityBInspect
Check whether AI answer-engines recommend a brand: 0-100 score, competitors winning, GEO fix-list. Paid: $4 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| brand | Yes | ||
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is paid ($4 USDC via x402) and gives output structure (0-100 score, competitors, GEO fix-list). Since no annotations are provided, this adds valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Front-loaded with the core purpose and key 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?
Adequate for a simple tool with no output schema and no annotations, but missing parameter semantics and usage guidance make it less 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 description coverage is 0%. The description does not explain what each parameter (url, brand, category) means or how to use them. Only 'brand' is required, but no details.
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: checking AI answer-engine visibility for a brand, with a 0-100 score, competitor info, and GEO fix-list. It distinguishes from siblings which are about general web data extraction or page reading.
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 this tool versus alternatives like extract_web_data or read_web_page. The mention of payment is a constraint but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_web_dataBInspect
Scrape a public URL into the exact structured JSON you ask for (prices, contacts, listings, specs). Paid: $0.05 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| instruction | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It discloses the paid nature and cost, but does not mention rate limits, authentication needs, response format guarantees, or error handling. The description adds some value beyond no information.
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 short, front-loaded sentences. First sentence states purpose clearly, second adds critical cost information. No wasted words. Well-structured for quick comprehension.
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?
Basic purpose and cost are covered, but given no output schema and minimal parameter info, the description should provide more guidance on how to structure the 'instruction' parameter, expected output format, and potential errors. Adequate for a simple tool but not 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 0%, so description must explain parameters. It implies 'url' is the target and 'instruction' specifies what to extract (e.g., prices, contacts). However, it does not explicitly describe the required format for 'instruction' or any constraints on 'url'. Marginal added value.
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 the verb 'scrape', resource 'public URL', and output 'structured JSON'. Examples of use cases (prices, contacts, listings) help clarify. However, it doesn't explicitly distinguish from sibling 'read_web_page', which could cause confusion.
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?
Mentions paid cost ($0.05 USDC) which implies a condition for use, but no explicit when-to-use or when-not-to-use. No alternatives or prohibitions are given. The cost is a notable factor but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vevang_agentsAInspect
List Vevang's live autonomous AI agents — what they do, prices, and endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output content (agent details, prices, endpoints) but does not mention any behavioral traits like read-only nature, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no waste, but it could be slightly more structured (e.g., listing the fields explicitly). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description covers the essential return values (what they do, prices, endpoints), making it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter 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 uses a specific verb ('List') and resource ('Vevang's live autonomous AI agents') and details what it returns (what they do, prices, endpoints), clearly differentiating it from sibling tools like check_ai_visibility or extract_web_data.
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 used to retrieve agent details, but it provides no explicit guidance on when to use this tool versus alternatives, nor any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_marketing_videoBInspect
Produce a finished, on-brand short marketing video from one prompt. Paid: $12 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| brand | No | ||
| aspect | No | 9:16 | |
| prompt | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits but only mentions payment and basic output. It omits details on error handling, rate limits, what 'on-brand' entails, and the outcome of payment failure, leaving significant gaps.
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 (one sentence plus a payment note) and front-loads the core purpose. It could be more structured (e.g., listing parameters) but avoids 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?
Given no annotations, no output schema, and 0% parameter descriptions, the description is incomplete. It lacks context on output format, error states, and the payment workflow, making it insufficient for reliable agent use.
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 add meaning. It only references 'from one prompt', ignoring url, brand, and aspect parameters. This fails to clarify their roles, defaults, or usage constraints beyond the schema's bare structure.
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 'Produce a finished, on-brand short marketing video from one prompt', specifying the verb (produce) and resource (marketing video). This distinguishes it from sibling tools like extract_web_data and verify_output, which handle data extraction and verification respectively.
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 usage for creating short marketing videos and notes the cost ($12 USDC via x402). However, it does not explicitly state when to use this tool versus alternatives, nor does it list prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_web_pageBInspect
Read any public URL as clean, LLM-ready markdown (main content + title + links). Paid: $0.01 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It reveals that the tool incurs a payment of $0.01 USDC via x402, which is significant. However, it omits details about failure modes, rate limits, or constraints on what constitutes a 'public URL'.
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 concise (two sentences) and front-loaded with the core purpose. Every word is necessary, and the structure is clear: function first, then cost.
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 lack of annotations, output schema, and minimal parameter documentation, the description should provide more context about expected inputs, outputs, and constraints. It only covers basic functionality and cost.
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 'url' has no schema description (0% coverage). The description adds only that the URL must be public, but does not specify format, allowed schemes, or provide examples.
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 reads a public URL and returns LLM-ready markdown with main content, title, and links. However, it does not differentiate from sibling tools like extract_web_data, which might have overlapping functionality.
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 provided on when to use this tool versus alternatives. The mention of payment is a cost consideration but does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_outputAInspect
Verify another agent's deliverable is real + meets spec before you pay for it. Paid: $1 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| deliverable | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that payment is required ('$1 USDC via x402'), which is a key behavioral trait. However, it does not describe what happens if verification fails, whether any data is modified, or the response format.
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 concise with two sentences, each carrying essential information: purpose and cost. No unnecessary words 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?
Given the tool has only two parameters, no output schema, and no annotations, the description provides basic purpose and payment info. However, it lacks details on the verification process, error handling, or what the output looks like, which may be needed for a paid 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%, and the description does not elaborate on the parameters. It only implies that 'spec' relates to the specification to check against, but does not explain the format or usage of 'deliverable' beyond being the item to verify.
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 the verb 'verify' with a clear resource 'another agent's deliverable' and adds context 'real + meets spec before you pay for it', which distinguishes it from sibling tools like check_ai_visibility or extract_web_data.
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 states when to use the tool ('before you pay for it'), providing clear context. It does not mention alternatives or when not to use, but the purpose is sufficiently clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!