Skip to main content
Glama

Auth Crawl

auth_crawl

Crawl an authenticated application session to map post-login pages and extract URLs with object references for access-control testing.

Instructions

[AGGRESSIVE — requires human approval] Crawl an application as a registered session and map what is behind the login.

session names a session from session_register; it is only sent to the host it was issued for.

Before crawling, the entry point is fetched with and without the session. If the two responses are identical the session authenticates nothing, and the crawl is refused — a list of public pages labelled "authenticated surface" would poison every conclusion drawn from it.

When a page turns out to be a single-page-app shell, its same-origin script bundles are fetched and mined for paths — API literals, request call sites, and the route table. Those become crawl seeds under the same guards as a link, and are counted separately in coverage so it is visible how much of the map a link crawler alone would have missed. max_bundles bounds the extra requests.

Returns the discovered URLs, the forms found (read-only ones submitted with empty values, state-changing ones reported and never touched), and — the useful part — the URLs carrying an object reference, which is what authz_compare must be pointed at. A URL with no identifier in it belongs to everyone and proves nothing about access control.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYes
sessionYes
timeoutNo
max_depthNo
max_pagesNo
max_bundlesNo
liveness_everyNo
max_form_submissionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv2.1.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is transparent about the tool's aggressive nature, the need for human approval, the session isolation behavior, and the handling of single-page-app bundles and state-changing forms. It explicitly states it never touches state-changing form submissions. No contradiction with the provided annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear paragraphs, each covering a distinct aspect (purpose, authentication check, SPA handling, output). It is concise and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the tool's output (discovered URLs, forms, object references), its relationship with authz_compare, and its place among other tools. It covers the key context needed for an agent to decide when and how to use it, including the human approval requirement and the refusal condition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains only 'session' and 'max_bundles' in passing. Other parameters like target, timeout, max_depth, max_pages, liveness_every, and max_form_submissions are not described beyond their schema types and defaults. With 0% schema description coverage, the description does not compensate for the missing parameter explanations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool crawls an application as a registered session to map the authenticated surface. It uses specific verbs and distinguishes its output (URLs with object references) from sibling tools like authz_compare and auth_surface.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to discover authenticated endpoints), explicitly mentions it requires human approval, and describes the refusal condition when the session authenticates nothing. It also instructs the user to point authz_compare at the discovered object-referencing URLs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamsecure1920/Cordon-AI'

If you have feedback or need assistance with the MCP directory API, please join our Discord server