WebsiteIQ
Server Details
Robots-aware website audits, pre-crawl quotes, and structured evidence for people and agents.
- 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
Score is being calculated. Check back soon.
Available Tools
6 toolsaudit_urlStart a WebsiteIQ auditAInspect
Starts the free bounded, robots-compliant audit of one public HTTP(S) page. No account, email, or contact consent is required. One free audit is allowed per requester IP and per target website each day. When payment is available, an abuse-limited call returns the exact sitemap-priced x402 PaymentRequired result and accepts a compatible retry through _meta['x402/payment']; otherwise it returns a quote preview. WebsiteIQ never pays target sites and never bypasses robots.txt.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public website URL to audit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| ok | Yes | |
| status | Yes | |
| pageCap | Yes | |
| reportUrl | Yes | |
| statusUrl | Yes | |
| retentionPolicy | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limits, robots compliance, payment flow, and ethical behavior (never pays sites, never bypasses robots.txt), adding significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value without redundancy. Concise and well-structured.
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?
Covers purpose, usage constraints, payment interaction, and ethical boundaries. No gaps given the tool's simplicity and the presence of an output schema and annotations.
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% with a minimal description ('Public website URL to audit'). The tool description adds little extra meaning about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (starts a free audit), the resource (one public HTTP(S) page), and distinguishes from siblings (free vs paid, no registration).
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?
Explicitly mentions no account needed, daily rate limits per IP and target, and payment handling scenarios, effectively guiding when to use and when not (e.g., for paid audits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_auditDelete auditDestructiveIdempotentInspect
Deletes the retained request metadata, generated report, and delivery record.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| accessToken | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| deleted | Yes |
estimate_auditGet a whole-site audit quoteARead-onlyIdempotentInspect
Before audit crawling, reads robots.txt and a bounded same-host sitemap tree—including namespaced, WordPress, and Yoast-style indexes—then returns page scope plus standard and white-label USDC quotes. Up to 10 pages cost $0.01 standard or $0.02 white-label; each additional page costs $0.001 or $0.002. A payable quote includes the quoteId required by start_paid_audit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public website URL whose robots-permitted sitemap should be counted. | |
| branding | No | Required when whiteLabel is true. | |
| whiteLabel | No | Return the white-label quote as selectedQuote. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| quoteId | Yes | |
| quoteStatus | Yes | |
| quotePayable | Yes | |
| paymentStatus | Yes | |
| pricingNotice | Yes | |
| pricingStatus | Yes | |
| selectedQuote | Yes | |
| standardQuote | Yes | |
| estimatedPages | Yes | |
| quoteExpiresAt | No | |
| whiteLabelQuote | Yes | |
| estimateComplete | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds concrete details about what it reads (robots.txt, sitemap) and provides pricing information, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. All information is front-loaded and essential.
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 annotations cover safety, schema covers parameters, and output schema exists, the description sufficiently covers prerequisites, pricing, and linkage to start_paid_audit.
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 100% of parameters. Description adds minimal new meaning (e.g., 'Public website URL whose robots-permitted sitemap should be counted' is mostly a restatement). Baseline 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 it reads robots.txt and sitemap trees, then returns page scope and quotes. It distinguishes itself from siblings like start_paid_audit by mentioning the quoteId requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Before audit crawling', indicating when to use. It also references start_paid_audit, guiding the agent to use this tool before starting a paid audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audit_statusGet audit statusARead-onlyIdempotentInspect
Returns the privacy-filtered status of an audit. The access token returned by audit_url is required.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| accessToken | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| ok | Yes | |
| status | Yes | |
| reportUrl | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying that the status is 'privacy-filtered' and that an access token from audit_url is required, which are behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no unnecessary words. The purpose is stated first, and the token requirement is immediately clarified. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key requirement (access token from audit_url) and the return type (privacy-filtered status). With an output schema present, return values need not be explained. However, it lacks guidance on the origin of the 'id' parameter and when to use the tool relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the accessToken parameter's origin (from audit_url) but does not describe the 'id' parameter at all, leaving its semantics unclear. This is insufficient for full understanding.
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 the 'privacy-filtered status of an audit', which is a specific verb and resource. It does not explicitly differentiate from sibling tools like delete_audit or start_paid_audit, but the purpose is clear.
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 by requiring the access token from audit_url, indicating a dependency. However, it does not provide explicit guidance on when to use this tool versus alternatives such as delete_audit or list_checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_checksList WebsiteIQ checksARead-onlyIdempotentInspect
Returns the current public audit categories and scoring caveat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| checks | Yes | |
| scoringNote | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the behavioral context that it returns public audit categories and a scoring caveat, which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, achieving maximum conciseness with no wasted verbiage.
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 parameters and an output schema, the description adequately covers the tool's purpose. However, it could explicitly mention that no arguments are required, though the schema already implies this.
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% with zero parameters, so baseline is 4. The description does not need to add parameter info, and it correctly implies no arguments are needed.
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 'current public audit categories and scoring caveat', providing a specific verb and resource. It distinguishes from sibling tools like audit_url and delete_audit by being a read-only listing operation.
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 like get_audit_status. The description does not indicate prerequisites or context for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_paid_auditPay for and start a quoted auditAIdempotentInspect
Starts the exact robots-aware whole-site scope represented by a current quoteId. If payment is absent, returns an x402 v2 PaymentRequired result. A compatible MCP client retries with _meta['x402/payment']; WebsiteIQ verifies the required payment identifier, settles exact USDC, and returns the existing job on safe replay.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteId | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| ok | Yes | |
| status | Yes | |
| pageCap | Yes | |
| payment | Yes | |
| quoteId | Yes | |
| reportUrl | Yes | |
| statusUrl | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true but not the payment protocol. The description adds significant value by disclosing the x402 payment requirement, retry with _meta['x402/payment'], and safe replay behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. The main action is front-loaded, and every sentence serves a purpose.
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 missing parameter guidance, the description covers the tool's core behavior, payment flow, idempotency, and expected response. Given the output schema exists (not shown), the description is complete enough for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so the description must compensate. It only mentions 'current quoteId' without explaining its format, origin, or role despite the schema providing a regex. This is insufficient for an agent to understand the parameter's purpose beyond the name.
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 verb ('Starts') and resource ('exact robots-aware whole-site scope represented by a current quoteId'). It distinguishes from siblings like 'audit_url' (which starts from a URL) and 'delete_audit' (different action).
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 use the tool (with a quoteId) and includes a detailed retry mechanism for payment. It lacks explicit 'when not to use' or comparisons to alternatives, but the payment context and retry flow provide good guidance.
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!