Website QA for your coding agent: audit SEO, performance, security, accessibility over MCP.
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 4.5/5 across 18 of 18 tools scored.
Every tool has a clear, distinct purpose: website management, audit lifecycle, issues, rules, credits, identity, and feedback. Overlapping operations like delete_website vs delete_websites and add_website vs run_audit are explicitly differentiated by scope and behavior, so an agent can reliably select the right tool.
All tool names follow the snake_case verb_noun pattern (add, comment, create, delete, get, list, run, send), making the toolset highly predictable. The only outlier is whoami, but it is a well-known conventional command name and does not disrupt the overall consistency.
At 18 tools, the count is slightly above the typical 3-15 well-scoped range, but each tool covers a distinct function in the audit platform (sites, audits, reports, issues, rules, credits, keys, feedback, identity). The count feels moderately heavy but not excessive, and no tool is redundant.
The core lifecycle is well covered: website registration/deletion, audit triggering/polling/report retrieval, issue listing/detail/comments, rule browsing, and credit tracking. Minor gaps exist—no way to update issue status or revoke API keys—but agents can work around these via comments and by relying on admin actions, so they are not critical dead ends.
add_websiteAdd a websiteAInspectRegister a website with the organization without running an audit (run_audit registers automatically, so this is only needed to set a site up ahead of time). Returns the website_id; idempotent per domain, so calling it again returns the existing website. Pass kind to classify it as owned or prospect up front.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL to register, e.g. https://example.com (scheme optional). | |
| kind | No | Classify the site: 'owned' for something the user runs and monitors, 'prospect' for a lead or competitor. Filterable in list_websites. Unclassified sites read as 'owned', so only an explicit 'prospect' makes a site show up in a prospect cleanup. Re-calling with a different value reclassifies it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: idempotency ('calling it again returns the existing website'), return value ('Returns the website_id'), and the default classification behavior ('unclassified sites read as "owned"'). This is rich context that annotations alone do not provide. No contradiction 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 that are front-loaded with the core purpose, then efficiently cover alternatives, side effects, return value, and parameter guidance. Every clause earns its place with 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?
For a simple two-parameter tool with no output schema, the description fully addresses prerequisites, behavior, and return value. It mentions idempotency, the relationship with run_audit, and classification semantics, leaving no critical gaps in understanding.
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 the schema already documents both 'url' and 'kind' thoroughly. The description adds only minor usage context ('Pass kind to classify it as owned or prospect up front'), which is helpful but largely redundant with the schema's detailed enum explanation. Baseline 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 action ('Register a website with the organization') and explicitly distinguishes it from run_audit by noting it does so 'without running an audit'. This makes the tool's purpose unambiguous and differentiates it from the most relevant sibling tool.
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 this tool is needed ('only needed to set a site up ahead of time') and names the alternative (run_audit) that also registers automatically. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
comment_on_issueComment on an issueAInspectPost a comment on a website issue — use it to record analysis, a proposed fix, or what you changed, so the team sees it in the dashboard issue thread. Markdown is supported.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Comment body (markdown supported). | |
| website_id | Yes | Website id the issue belongs to. | |
| issue_number | Yes | Issue number from list_issues. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by mentioning that comments support Markdown and appear in the dashboard issue thread. Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false, which are consistent. No contradictions.
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 long, front-loads the main purpose, and avoids any wasted words. The Markdown hint is appended efficiently.
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 comment-posting tool with no output schema, the description covers the core functionality, usage context, and a key feature (Markdown). It is complete enough for an agent to select and invoke 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 100%, so baseline is 3. The description adds contextual meaning by stating that the body supports Markdown and that the comment is posted to a thread visible to the team. This aids understanding beyond the schema descriptions.
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 'Post' and the resource 'comment on a website issue'. It further specifies the purpose: to record analysis, proposed fix, or changes, and distinguishes it from sibling tools like delete_website or list_issues by focusing on comment threads.
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 says when to use the tool (to record analysis, fix, or changes) and provides context ('so the team sees it in the dashboard issue thread'). It does not explicitly state when not to use it, but the sibling tools list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_api_keyCreate an API keyAInspectMint a new squirrelscan API key for this organization (requires credentials carrying the keys:write scope, which OAuth sign-in grants). The key is returned EXACTLY ONCE: show it to the user immediately and suggest saving it as the SQUIRRELSCAN_API_KEY environment variable for the CLI, CI, and MCP. Minted keys cannot themselves mint keys.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable label shown in the dashboard, e.g. "ci" or "claude-code". | |
| scopes | No | Scopes to grant (default: audits:write, audits:read, credits:read, org:read). Grantable: audits:write, audits:read, credits:read, org:read, org:write. | |
| expires_in_days | No | Expire the key after this many days (default: never expires). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key returned exactly once, scope requirement, and inheritance restriction. This adds significant behavioral context beyond annotations (readOnlyHint=false, destructiveHint=false). No 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?
Two sentences clearly structured: purpose, important note, restriction. No wasted words, front-loaded with action.
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?
Adequately explains the one-time return behavior, but lacks explicit output schema or format details for the returned key. Minor gap for a creation 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 coverage is 100%, but description adds value with examples for name, defaults and list for scopes, and default behavior for expires_in_days. Exceeds baseline of 3.
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 specifies 'Mint a new squirrelscan API key for this organization' with a distinct verb and resource. No sibling tool creates API keys, so it is well-distinguished.
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 context on required scope (keys:write), OAuth, and immediate action (show user, suggest env var). Also notes that minted keys cannot mint keys. Does not explicitly state when not to use, but no alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_websiteDelete a websiteADelete a website from the organization (soft delete: past audits, reports, and issues are preserved, and published report links keep working). Frees a slot under the plan's website limit. Re-adding the same domain later registers a fresh website with a new website_id. Call once without confirm to see what will happen; call again with confirm: true to delete. To remove many sites at once, use delete_websites.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Approve the deletion. Omit on the first call to see the effect; set true to delete after the user approves. | |
| website_id | Yes | Website id from list_websites, run_audit, or add_website. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but description adds substantial context: soft delete preserves audits/reports/issues, published links keep working, frees a plan slot, and re-adding creates a new website_id. It also discloses the confirm-step behavior. No contradiction 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?
Four sentences, each delivers a distinct piece of information: soft-delete semantics, slot effect, re-add behavior, and confirmation workflow plus bulk alternative. No redundant words; front-loaded with the core action.
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 tool's destructive nature is fully contextualized: safety workflow, side effects, and alternative for bulk deletion are all covered. No output schema is needed, and the description provides complete guidance for a complex action.
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 detailed descriptions for both website_id and confirm. The description reinforces the confirm parameter's purpose through the two-step workflow but does not add meaning beyond what the schema already provides. Baseline 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 opens with 'Delete a website from the organization' – a specific verb and resource with scope. It immediately distinguishes itself from the sibling delete_websites by noting bulk deletion separately. The soft-delete behavior and slot freeing further clarify the exact function.
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 describes the two-call workflow (without confirm, then with confirm) and names the alternative for bulk deletion: 'To remove many sites at once, use delete_websites.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_websitesDelete websites in bulkADelete up to 50 websites in one call, for cleaning up a dashboard that has filled with one-off or prospect audits. Same soft delete as delete_website (past audits, reports, and issues are preserved, published report links keep working, slots are freed) and the same two-step confirm: call once without confirm to see the domain behind every id, then again with confirm: true. EVERY result echoes the domain, so read them back to the user before and after: an id is not a name, and this is the tool most likely to be pointed at the wrong list. The preview also shows each site's kind and an owned_count: unclassified sites read as owned, so an 'owned' entry in a list you built from prospects is the clearest sign the wrong ids were assembled. Ids that do not resolve are reported per-id, never as a whole-call failure. To pick the ids, list_websites with kind: "prospect" returns only sites explicitly marked disposable.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Approve the deletions. Omit on the first call to see which domain each id resolves to; set true to delete after the user approves. | |
| website_ids | Yes | Website ids from list_websites (1 to 50). Duplicates are collapsed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description richly discloses behavior: soft-delete semantics, two-step confirm, per-ID error handling, the preview showing owned_count, and the caveat about unclassified sites. This adds significant value and context not available from annotations alone. 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 a single dense paragraph, but every sentence carries important operational or safety information. It is front-loaded with the core action, and while long, the complexity of the tool justifies the length. No fluff.
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 destructive bulk tool with no output schema, the description covers all critical aspects: what happens on delete, how preview works, how to verify IDs, what errors occur, and how to correctly source IDs. It is fully complete for an agent to safely invoke the 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 coverage is 100% for both parameters, but the description adds practical semantics: the two-step confirm workflow, that website_ids should come from list_websites, and that duplicates are collapsed. It also warns that every result echoes the domain, reinforcing the importance of confirm. This goes beyond the schema descriptions.
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 'Delete up to 50 websites in one call', which is a specific verb, resource, and scope that distinguishes it from the sibling delete_website. It also provides the use case ('cleaning up a dashboard') and the bulk nature, making the purpose 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?
The description gives clear context on when to use it ('for cleaning up a dashboard filled with one-off or prospect audits') and explicitly points to list_websites as the way to select IDs. It does not explicitly state when to use delete_website instead, but the bulk vs. single distinction is implied through the max 50 limit and the reference to 'same soft delete as delete_website'.
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 statusAPoll a running audit by run_id (from run_audit or list_audits). Status pending/running means keep polling (every 15-30 seconds) — the response includes a progress field (phase, message, page/link counts) when available. Status completed means the report is ready: call get_report with the same run_id. Status failed/cancelled includes the error and completion reason.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | Run id returned by run_audit or listed by list_audits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns a progress field and is meant for polling, which provides useful context beyond the 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?
Three sentences, no wasted words, front-loaded with purpose and key guidance on polling frequency and status handling.
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?
No output schema, but description covers what the response contains (progress field with phase, message, counts; error for failures). Links to get_report for completed audits, making the workflow clear.
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 has 100% coverage for run_id, so schema already explains it. Description adds that run_id comes from run_audit or list_audits, but this is a minor addition.
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 polls a running audit by run_id, distinguishing it from sibling tools like get_report (for completed audits) and run_audit (which initiates audits).
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 tells when to use (polling), what to expect for each status (pending/running: keep polling every 15-30 seconds; completed: call get_report; failed/cancelled: includes error), and links to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_credit_balanceGet credit balanceAGet the organization's credit balance: monthly credits (reset each billing period) and pack credits (purchased, never expire). Audits spend credits pay-as-you-go while they run; run_audit shows an upper-bound estimate before starting. Top up at https://app.squirrelscan.com/billing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: details credit types (monthly vs pack), how audits spend credits, and where to top up. Annotations already indicate read-only and non-destructive nature, but description enhances understanding of behavior.
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, each delivering high-value information: purpose, credit types, audit consumption, and billing link. No unnecessary 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?
Given zero parameters and no output schema, the description provides a thorough overview of what the tool returns and how credits work. Could mention response format, but not required for completeness.
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?
No parameters exist, so baseline score applies. Schema coverage is 100%, and description adds no parameter info, which is appropriate since there are none.
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 retrieves the organization's credit balance, distinguishes two types of credits (monthly and pack), and explains their properties. It differentiates from siblings by focusing on billing rather than audits or issues.
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 context for when to use (to check balance) and explains how audits consume credits, with a reference to run_audit for an estimate. Does not explicitly state when not to use, but sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_issueGet issue detailAFetch one issue by website_id + issue number, including its full description, recommendation, affected pages, occurrence detail from the latest report (which page/image/URL, snippets), and comment thread. Use comment_on_issue to add analysis or a fix note to the thread.
| Name | Required | Description | Default |
|---|---|---|---|
| website_id | Yes | Website id the issue belongs to. | |
| issue_number | Yes | Issue number from list_issues. | |
| occurrence_limit | No | Max occurrences to include (default 20); see occurrence_count/truncated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds useful context about the returned data (full description, recommendation, affected pages, occurrences from latest report, comment thread), 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, zero waste. The first sentence front-loads the purpose and key parameters, and the second sentence provides a cross-reference to a sibling tool. All content 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?
For a read tool with simple parameters and no output schema, the description reasonably covers what the tool returns. It could mention the occurrence_limit parameter or error handling, but the current description is sufficient for an AI agent to understand the tool's capabilities.
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 descriptions for all three parameters (website_id, issue_number, occurrence_limit). The description only mentions website_id and issue_number, adding no extra meaning beyond what the schema provides. The occurrence_limit parameter is not referenced, but its schema description is adequate. 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 the verb 'Fetch', the resource 'issue', the identifying keys 'website_id + issue number', and lists the included fields (description, recommendation, affected pages, occurrence detail, comment thread). It also distinguishes itself from the sibling 'comment_on_issue' by directing the user to that tool for adding notes.
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 tells the user to use 'comment_on_issue' for adding analysis or fix notes, providing a clear when-not scenario. However, it does not explicitly state when to use this tool versus other siblings like 'list_issues', though the purpose is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportGet audit reportAFetch the finished report for an audit run (use the run_id from run_audit once get_audit_status shows completed). Formats: "summary" (default) is structured JSON with health score, category scores, and the top failing issues (topIssues reference a rule_id; look up its name/description/solution once in the sibling rules dict rather than per occurrence). Each topIssues row carries provenance: "carried" means the finding is re-injected from a page not re-crawled this run (not a fresh result) — check lastSeenAt for when it was last actually observed. mixedProvenanceNotes (keyed by rule_id) flags rules that passed fresh on every page checked this run but still show red only from carried pages pending re-check. Also includes a history array of prior audits of this website with score/issue deltas when available; each entry carries its own runId/reportId, so you can walk backwards through a website's audits by calling get_report again with an earlier runId (use list_audits with website_id to page past what history returns); "llm" is a compact text rendering optimized for LLM context (carried findings marked inline); "markdown" is a full human-readable report. Start with summary, then pull llm or markdown when you need every issue and page detail.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | summary (default): JSON scores + top issues. llm: compact text for LLM context. markdown: full report. | |
| run_id | Yes | Run id returned by run_audit or listed by list_audits. | |
| top_issue_limit | No | summary format only: max top issues to include (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals key behaviors: report structure, provenance semantics ('carried' findings), lastSeenAt, mixedProvenanceNotes, and the ability to walk backwards through audits via prior runId. 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 long but front-loaded with purpose and key workflow. Every clause provides useful detail; however, the single dense paragraph could be broken into bullets for easier scanning. Slight deduction for structure, not 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 no output schema, the description fully explains what summary returns (health score, category scores, top issues), llm and markdown content, provenance handling, and history traversal. It covers all necessary context for an agent to use the tool effectively.
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%, but the description adds significant meaning: run_id source and lifecycle, format differences and default, top_issue_limit use, and the semantics of each format's output. This goes well beyond the basic property descriptions.
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 opens with 'Fetch the finished report for an audit run', clearly stating the verb and resource. It distinguishes itself from siblings by detailing the report formats and its role in the audit workflow, complementing run_audit and get_audit_status.
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 instructs when to use: after get_audit_status shows completed, using run_id from run_audit. It also recommends starting with 'summary' and switching to 'llm' or 'markdown' when more detail is needed, and references list_audits for walking through history. This provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ruleGet rule detailAFetch one audit rule by id (e.g. "meta/title-length"), including what it checks, how to fix it (recommendation), its severity and score weight, a docs link, and whether it is a cloud (credit-billed) rule. Rule ids appear in report topIssues and issue rule_id fields.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes | Rule id like "crawl/canonical-chain" (category/slug). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds specific return fields and context (e.g., cloud flag, docs link), enhancing transparency beyond annotations 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?
Two concise sentences front-loaded with purpose; every sentence adds essential detail without fluff.
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 low complexity (1 param, no output schema, annotations present), description fully covers what the tool returns and why it's useful, including source of rule ids.
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 the single parameter with description, but description adds examples (e.g., 'meta/title-length') and context on where rule ids appear, providing additional value beyond 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 fetches one audit rule by id, listing specific fields like checks, recommendation, severity, score weight, docs link, and cloud flag. It distinguishes from sibling list_rules by specifying single rule retrieval.
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 when to use (fetch a specific rule by id) and where rule ids come from (report topIssues, issue rule_id). Implies not for listing all rules, but does not explicitly state alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_auditsList auditsAList the organization's audit runs: currently active (pending/running) plus recent runs of any status. Pass website_id (from list_websites) to get one website's full audit history, oldest runs included, and page through it with limit/offset using the returned total/has_more. This is the way to reach the preserved reports of a soft-deleted website: its runs still list under its old website_id. total/has_more describe the recent array only, and recent already includes any pending/running run, so active is a live view of those same runs and not extra items to add to the count. Use the run ids with get_audit_status or get_report, and website ids with list_issues.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max recent runs to return (default 20, max 100). | |
| offset | No | Pagination offset into the recent runs (default 0). Use with total/has_more. | |
| website_id | No | Only return runs of this website (id from list_websites, run_audit, or add_website). Works for soft-deleted websites too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true already provided, the description adds significant behavioral nuance: it explains that total/has_more refer only to the recent array, that active runs are a live subset of recent (not additional items), and that soft-deleted website runs remain listable. This goes well beyond the annotations and prevents common misinterpretations.
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 but every sentence serves a purpose: main purpose, optional scoping, soft-delete nuance, pagination semantics, and cross-references to sibling tools. It is front-loaded with the essential listing behavior and does not waste 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?
Without an output schema, the description must explain return semantics, and it does: the relationship between active and recent, total/has_more pagination, and how to use results with related tools. It provides enough context for an agent to invoke the tool correctly and interpret the response, making it complete for a list operation.
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% for all three parameters, so baseline is 3. The description adds value by explaining the provenance of website_id (from list_websites, run_audit, or add_website) and emphasizing its utility for soft-deleted websites, which goes beyond the schema's generic description. Pagination semantics are also reinforced.
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 opens with a clear, specific verb and resource: 'List the organization's audit runs', and immediately distinguishes between active and recent runs. It further sets itself apart from sibling tools by noting how run ids should be used with get_audit_status or get_report, making the purpose 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?
The description provides strong contextual usage guidance, explaining when to pass website_id to get full history and how to access soft-deleted website reports. It also hints at alternatives by directing users to other tools for follow-up actions, though it doesn't explicitly state 'do not use this tool for X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_credit_transactionsList credit transactionsAAudit the organization's credit accounting log: grants (signup/monthly/pack/promo), debits (audit_base 50cr + render 2cr/page + folded 0-cost services), refunds, and adjustments — newest first, paginated. Each debit/refund carries run_id so you can group a single audit's spend. Use this to explain why an audit cost what it cost or to reconcile a balance. For one audit's per-feature breakdown, use get_report (its cost field). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max transactions to return (default 25, max 100). | |
| cursor | No | Opaque pagination cursor from a previous page's `next_cursor`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds behavioral details: each debit/refund carries run_id for grouping, pagination, and explicit 'Read-only' confirmation. 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?
Description is well-structured, front-loaded with purpose, then details, then usage. While comprehensive, it is efficient and every sentence adds value. Slightly longer than minimal, but not verbose.
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?
No output schema, but description explains return details: newest first, each entry includes run_id, pagination via cursor. Covers what the agent needs to know to interpret results and use effectively.
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 both parameters described (limit with default and max, cursor as opaque pagination token). Description does not add additional semantics beyond schema; 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?
Description clearly states the tool audits the organization's credit accounting log, listing grants, debits, refunds, adjustments. It distinguishes from get_report (per-feature breakdown) and get_credit_balance (balance), and specifies ordering (newest first, paginated).
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?
Explicit usage guidance: 'Use this to explain why an audit cost what it cost or to reconcile a balance.' Also directs to use get_report for per-feature breakdown, clearly differentiating when to use this tool vs sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_issuesList website issuesAList a website's open audit issues (like a bug tracker: each issue is one failing rule with occurrences across pages, numbered per website). Returns issues sorted by severity, plus severity and status summaries. Use the issue number with get_issue for full detail and comments. Filter by status/severity/category to narrow down.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 50). | |
| offset | No | Pagination offset (default 0). | |
| status | No | Filter by issue status (omit for all statuses). | |
| category | No | Filter by rule category code (e.g. seo, performance, security). | |
| severity | No | Filter by severity. | |
| website_id | Yes | Website id from list_websites, run_audit, or list_audits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's addition that results are sorted by severity and include summaries provides useful extra context. No contradictory or missing behavioral notes.
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 front-loaded with the core purpose, uses efficient sentences, and avoids unnecessary detail. Every sentence adds value.
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 output schema, the description adequately explains the return value (sorted list with summaries) and links to get_issue for details. Pagination parameters are covered in the schema, so no gap.
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?
All parameters have schema descriptions with 100% coverage. The description reiterates the filter options but does not add new meaning beyond the schema, so the baseline 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 lists a website's open audit issues, compares to a bug tracker, and explains what each issue represents. It explicitly distinguishes from the sibling get_issue tool.
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 using this tool and directs users to get_issue for full details. It mentions available filters but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rulesList audit rulesABrowse the catalog of 260+ audit rules that run during an audit, grouped into categories (crawlability, meta tags, performance, security, accessibility, content, and more). Filter by category code or search by keyword to find what a specific rule checks. Use get_rule for one rule's full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Case-insensitive keyword match on rule id, name, and description. | |
| category | No | Filter to one category code (see the categories list in the response). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Adds behavioral context about catalog size and grouping. No contradiction. Slight deduction for not detailing pagination or 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?
Two sentences that front-load purpose and grouping, then provide usage guidance and sibling reference. 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?
Provides catalog size, grouping, and filtering context. Lacks description of response fields beyond categories, but sufficient for a list tool given good schema.
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%, so baseline is 3. Description adds minimal extra beyond the schema parameter descriptions, essentially paraphrasing filter/search behavior.
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 verb 'browse' and resource 'audit rules' are clear. It distinguishes from sibling 'get_rule' by directing users to that tool for full details.
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 states how to filter (by category or keyword) and when to use an alternative ('Use get_rule for one rule's full detail'). Provides context like '260+ rules' and grouping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_websitesList websitesAList websites the organization has audited, with their latest run status, health score, and owned/prospect kind. Each row carries last_run_id (the latest run, any status) and last_report_run_id / last_report_id (the latest completed run whose report has not been deleted) — pass last_report_run_id to get_report to read a website's newest report without knowing a run id in advance, or list_audits with website_id for its full history. Use the website_id with list_issues/get_issue. Websites registered but never audited do not appear; run_audit or add_website registers a new one. Ephemeral one-shot audits never appear. Returns total/has_more for pagination. Filter by kind to separate sites the user runs from one-off prospect audits: kind: "prospect" returns ONLY sites explicitly marked as such, so it is the safe way to build a bulk-delete list.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by classification. Unclassified sites count as 'owned', so 'prospect' never returns a site nobody explicitly marked disposable. Omit for all websites. | |
| limit | No | Page size (default 50). | |
| offset | No | Pagination offset (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description discloses that unregistered and ephemeral one-shot audits are omitted, that last_report_run_id points to the latest completed report whose report was not deleted, and that the response includes total/has_more for pagination. This adds meaningful behavioral context without contradicting any annotation.
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 front-loaded, with the main purpose in the first sentence. It is longer than average but every clause adds operational detail (ID relationships, exclusions, pagination, filter semantics). A slight trim could improve readability, but no sentence is wasted.
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 list tool with no output schema, the description covers return fields, pagination, filtering semantics, exclusions, and cross-tool ID usage. It anticipates likely follow-up actions (get_report, list_audits, list_issues) and provides enough context to invoke the tool correctly and interpret results. This is exceptionally 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?
While the schema already covers all three parameters with descriptions, the description enriches the meaning of 'kind' by explaining that unclassified sites count as 'owned' and that 'prospect' only returns explicitly marked sites. It also clarifies pagination semantics (default limit, offset behavior) and the difference between last_run_id and last_report_run_id, adding real value 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 opens with a specific verb ('List') and resource ('websites the organization has audited'), and immediately defines the contained fields (latest run status, health score, kind). It distinguishes itself from sibling tools by naming how its IDs relate to get_report, list_audits, list_issues, and by clarifying that unregistered/unused websites are excluded.
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 explicit usage direction: pass last_report_run_id to get_report, use website_id with list_issues/get_issue, and use list_audits for full history. It also states when to use kind=prospect for bulk deletion and that run_audit/add_website are for new registrations, effectively defining when this tool is and isn't appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_auditRun a cloud auditAInspectRun a cloud audit of a website (crawl + 260+ rule analysis + report). Credits are spent as the audit runs (pay-as-you-go). The dry run is optional: pass confirm: true on the first call to start straight away. Without confirm, an audit whose estimate is over the org's auto-run threshold comes back as status "confirmation_required" with the estimate to show the user, and you call again with confirm: true; one at or under the threshold just starts. Use max_pages to size the crawl (max_pages: 1 audits just the entry URL, the cheapest run). Audits are asynchronous and take minutes: poll get_audit_status with the returned run_id, then fetch results with get_report. The website is registered automatically on first audit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL to audit, e.g. https://example.com (scheme optional). | |
| kind | No | Classify the site: 'owned' for something the user runs and monitors, 'prospect' for a lead or competitor audited once. Filterable in list_websites so a prospect cleanup can never sweep up a live site. Unclassified sites read as 'owned'. Ignored when ephemeral is true (an ephemeral site never joins the list). | |
| render | No | Render pages in a headless browser (default true). Catches JavaScript-dependent issues; costs extra credits per page. | |
| confirm | No | Approve the credit spend. Set true to start immediately. Omitting it returns an estimate first for anything over the auto-run threshold, and starts the audit anyway for anything at or under it. | |
| coverage | No | Crawl coverage profile (default fast, 10 pages). Deeper coverage crawls more pages and costs more credits. | |
| ephemeral | No | One-shot check: run the audit and return the report without adding the site to the organization's website list, and without consuming a slot against the plan's website limit. Use for any 'just check this URL' audit the user is not going to monitor. The site is removed automatically once the audit finishes; get_audit_status and get_report keep working on the run_id. Ignored if the domain is already registered, in which case the audit runs against the existing tracked site (nothing is ever deleted) and the response reports ephemeral: false. | |
| max_pages | No | Cap the crawl at this many pages for this run. Overrides the coverage profile's page count, so max_pages: 1 audits just the entry URL for the cheapest possible run. A value above the plan's per-audit page ceiling is clamped to the ceiling and reported back in a notice, not rejected. | |
| max_credits | No | Spend guard: refuse to start if the upper-bound estimate exceeds this many credits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds crucial behavioral context: pay-as-you-go credit spend, the dry-run/confirmation flow, asynchronous execution, auto-registration of the website, and the existence of an auto-run threshold. This goes far beyond annotations and gives the agent a clear model of side effects.
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 dense paragraph, front-loaded with the core purpose and then explaining the confirmation flow, sizing, async behavior, and auto-registration. Every sentence adds value, though it could be broken into bullets for readability. It earns a 4 rather than a 5 due to moderate length.
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 complexity (8 params, async, credits, confirmation, auto-registration), the description covers all key operational aspects: cost, confirmation threshold, polling workflow, max_pages sizing, and auto-registration. It also correctly points to sibling tools for follow-up. The lack of an output schema is offset by pointing to get_audit_status and get_report.
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 the baseline is 3. The description adds workflow-level meaning for confirm (dry-run behavior) and max_pages (cheapest run), which helps the agent understand how parameters interact in practice. It does not add detail for every parameter, but the schema already handles those, and the added semantics justify a 4.
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: 'Run a cloud audit of a website (crawl + 260+ rule analysis + report).' It uses a specific verb and resource, and distinguishes itself from sibling tools like get_audit_status and get_report by explaining the asynchronous hand-off.
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 guidance on when to use the tool: how to start immediately with confirm: true, how the confirmation_required flow works, when to poll get_audit_status, and when to use max_pages for sizing. It also implies when not to use it (e.g., for checking progress or results) by naming the appropriate sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedbackAInspectReport your experience using squirrelscan mid-session: a bug, a missing feature, what worked, what confused you, missing report data, or tool ergonomics. Reviewed by the team to improve the product — use it any time something surprises you, not just at the end of a session. Works with any authenticated credentials, including read-only API keys.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | Audit run id this feedback relates to, if any (from run_audit/get_report). Verified against your credentials' runs before being attached. | |
| message | Yes | Free-text feedback (truncated at 2000 chars). | |
| category | Yes | bug_report (a defect in squirrelscan itself — wrong or missing rule result, crash, broken tool), feature_request (something squirrelscan should do but doesn't), what_worked (something worked well), confusing (unclear response/behavior), missing_data (a report or tool response was missing something you needed), tool_ergonomics (awkward tool shape/args/naming), or other. | |
| website_id | No | Website id this feedback relates to, if any (from list_websites). Verified against your org's websites before being attached. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false (write) and destructiveHint=false (non-destructive). Description confirms it is for feedback submission, reviewed by team, and works with any credentials. No contradictions or missing behavioral details.
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 long, front-loaded with action and purpose. Every sentence adds value without 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?
For a feedback submission tool with no output schema, the description fully explains its purpose, usage timing, and compatibility. All parameters are well-documented in the schema. No gaps.
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 baseline is 3. The description itself does not repeat parameter details but provides overall context. No additional semantic value beyond the schema is added by the description text.
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 specific verbs ('report your experience') and resource ('squirrelscan mid-session'), clearly distinguishing it from sibling tools (no other feedback tool exists).
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 states when to use ('any time something surprises you, not just at the end of a session'). Does not explicitly mention when not to use, but alternatives are not needed since no feedback sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiWho am IAIdentify the current credentials: how you are authenticated, which organization you act for, the plan, and the current credit balance. Call this first in a session to orient yourself before running audits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds specific behavioral context about what information is returned (credentials, organization, plan, credit balance), which is useful beyond the 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 long, front-loads the action ('Identify'), and provides all necessary information without unnecessary 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?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains the tool's purpose and return value. It is complete for an identity/authentication 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?
The tool has no parameters, so the description does not need to add parameter meaning. With schema description coverage at 100% (empty schema), a baseline score of 4 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 'Identify the current credentials: how you are authenticated, which organization you act for, the plan, and the current credit balance.' It uses a specific verb and resource, and the nature of checking credentials distinguishes it from sibling tools like list_websites or get_issue.
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 says 'Call this first in a session to orient yourself before running audits,' providing clear context for when to use it. However, it does not mention when not to use it or alternatives, so it falls short of a perfect 5.
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!
Sign in to create a connector for this server.
