Skip to main content
Glama
Sign In

Excession Labs: site search and security test requests

by ai.excessionlabs
OverviewDiscussionsAdmin

Request a security test from Excession Labs

request_security_test

Send a request for a security test (web application, API, multi-tenant SaaS isolation or AI application) to Excession Labs on behalf of a person who asked for it. Needs an agent key (POST https://excessionlabs.ai/agent/auth, then Authorization: Bearer ). Excession Labs replies to the person by email to agree scope; testing starts only after a written scope and written authorization from the system owner. Never include passwords, API keys or customer data. Limits: 5 requests a day per key, 3 a day per email address.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "email": "<email>",
      "test_type": "<test_type>",
      "targets": "<targets>",
      "person_consent": "<person_consent>",
      "authorized": "<authorized>"
    },
    "name": "request_security_test"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe person's name
emailYesThe person's work email; Excession Labs replies here
notesNoOther context from the person, up to 2,000 characters. No credentials or customer data.
reasonNoWhy the person needs the test
companyNoThe person's company or organization name
targetsYesSystems to test: URLs, API base URLs or short descriptions. No credentials.
websiteNoCompany website
timelineNoWhen the person needs the result, in their words
test_typeYesKind of test: web_app, api, saas_multi_tenant, ai_application (LLM app or agent) or other
authorizedYesMust be true: the person owns these systems or may arrange a test of them
person_consentYesMust be true: the person asked for this request and agreed to be contacted by email

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (which only say non-read-only, open-world, non-idempotent, non-destructive), the description discloses the auth flow (POST to the auth endpoint, then Bearer token), the downstream process (Excession Labs emails the person to agree scope; testing starts only after written scope and authorization), a data-handling prohibition, and concrete rate limits of 5/day per key and 3/day per email. This is exactly the operational context annotations cannot carry.

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?

Four compact sentences ordered by importance: what it does, how to authenticate, what happens next, what not to include, then limits. No filler, no repetition of the title, and the hard constraints are front-loaded enough to be read before the schema.

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?

For an 11-parameter, non-idempotent outbound submission tool with no output schema, the description covers authentication, the human confirmation loop, the authorization precondition, data exclusions, and rate limits. An agent has everything needed to decide whether to call it and what to expect afterwards.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented in the schema, including the must-be-true semantics of person_consent and authorized and the email reply destination. The description reinforces the no-credentials rule for notes and targets but adds little parameter-level meaning the schema does not already provide, so the baseline 3 applies.

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 first sentence gives a specific verb (send a request), a specific resource (security test), the recipient (Excession Labs), and enumerates the covered test kinds (web app, API, multi-tenant SaaS isolation, AI application). It is unmistakably distinct from the read-only site siblings (get_page, search_site, list_models), so an agent can select it without opening the schema.

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

Usage Guidelines4/5

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

It states the qualifying condition clearly: the request is made on behalf of a person who asked for it, and testing only proceeds after written scope and written authorization from the system owner. There is no explicit when-not guidance or named alternative, but no sibling competes for this job, so the gap is minor.

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

All Excession Labs: site search and security test requests toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources