Skip to main content
Glama

Auth: Others/Basic Auth

auth_others_basic_auth
Read-only

Send basic-auth credentials to a protected test endpoint: correct default username and password return 200, while invalid credentials return 401.

Instructions

This endpoint simulates a basic-auth protected endpoint. The endpoint accepts a default username and password and returns a status code of 200 ok only if the same is provided. Otherwise it will return a status code 401 unauthorized.

Username: postman

Password: password

To use this endpoint, send a request with the header Authorization: Basic cG9zdG1hbjpwYXNzd29yZA==. The cryptic latter half of the header value is a base64 encoded concatenation of the default username and password. Using Postman, to send this request, you can simply fill in the username and password in the "Authorization" tab and Postman will do the rest for you.

To know more about basic authentication, refer to the Basic Access Authentication wikipedia article. The article on authentication helpers elaborates how to use the same within the Postman app.

(Postman request: Auth: Others/Basic Auth | GET https://postman-echo.com/basic-auth)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "auth_others_basic_auth"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely useful behavior beyond that: the exact acceptance condition (hardcoded `postman`/`password`), the 200 vs 401 status outcomes, and the required base64 header value. It stops short of saying what the success response body contains.

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

Conciseness3/5

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

The core facts (credentials, header, 200/401) are front-loaded, which is good. However, the remaining bulk is padding: a base64 explanation, step-by-step Postman UI instructions, Wikipedia and Postman docs links, and a repeated Postman request line that duplicates the tool name and title. Roughly half the text does not help an agent invoke the tool.

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

Completeness4/5

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

With no parameters, no output schema, and annotations covering the safety profile, the description supplies what an agent needs: the auth scheme, the accepted credentials, and the two possible status outcomes. Only the shape of a successful response body is left unspecified, a minor gap for a test echo endpoint.

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

Parameters4/5

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

The input schema is an empty object with no properties, and the description correctly implies no input is needed beyond the pre-baked credentials. Baseline of 4 applies for zero-parameter tools; nothing is misleading about the absence of parameters.

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

Purpose4/5

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

The description states a specific verb and resource: it simulates a basic-auth protected endpoint that returns 200 on matching credentials and 401 otherwise. That is unambiguous. It never names or contrasts with the sibling auth tools (digest auth, OAuth 1.0), so the differentiation is left to the tool name rather than being stated.

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

Usage Guidelines3/5

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

It gives detailed instructions on how to construct an `Authorization: Basic ...` header, which implies the usage scenario (testing basic-auth handling). But there is no explicit when-to-use/when-not guidance relative to `auth_digest_digestauth_request` or `auth_others_oauth1_0_verify_signature`, and the header advice is not actionable for a zero-parameter MCP tool since the client cannot supply it.

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