Skip to main content
Glama

nohumans.directory

by directory.nohumans

resolve_endpoint

Read-onlyIdempotent

Pre-spend verdict on an endpoint URL you already hold — from another catalog, a prompt, a config, anywhere: check before paying instead of buying to find out. Returns match 'active' with the same full record as get_service_details (status, reputation score, paid_verification with on-chain tx proof, observed 402 protocol detail), match 'delisted' if the endpoint was listed here and later removed (treat as a warning), or a not-listed result. IMPORTANT: not-listed means never checked here, NOT unsafe — absence of a record is not a verdict either way. Use this as the pre-spend check when you have a URL in hand and no listing id; use find_paid_service instead when you have a need but no URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe endpoint URL exactly as you hold it, including any query string (parameterized listings bake params into the URL, so the query string matters). Trailing slashes and http/https differences are tolerated.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
matchYes
detailNo

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnly/openWorld/idempotent annotations. It explains the three possible outcomes ('active', 'delisted', not-listed), warns that delisted should be treated as a warning, and emphasizes that an absence of a record is not a safety verdict. This is exactly the kind of nuanced behavioral context an agent needs.

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 front-loaded with the core purpose and then efficiently covers return variants, the critical not-listed caveat, and explicit usage routing. Each sentence earns its place; there is no repetition or filler.

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 is complete for selection and invocation: it explains when to use the tool, what the outcome variants mean, how to interpret a not-listed result, and the parameter schema fully documents the URL format. Combined with strong annotations and an output schema, nothing critical is missing.

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?

The input schema already provides 100% coverage for the single url parameter, including exact-match guidance, query-string significance, and tolerance for trailing slashes and http/https differences. The description adds source context ('from another catalog, a prompt, a config') but does not fundamentally extend the parameter semantics beyond the schema.

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 opens with a clear and specific purpose: 'Pre-spend verdict on an endpoint URL you already hold.' It distinguishes itself from siblings by framing the use case as having a URL but no listing id, and explicitly contrasts with find_paid_service for need-without-URL scenarios.

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 gives explicit usage guidance: use this tool as the pre-spend check when you have a URL in hand and no listing id, and use find_paid_service instead when you have a need but no URL. It also clarifies the meaning of the not-listed outcome, preventing a likely misinterpretation.

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

All nohumans.directory toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct entry point: find_paid_service searches by need, get_service_details fetches by listing id, and resolve_endpoint checks a URL already in hand. The only close pair, get_service_details and resolve_endpoint, is clearly separated by input type and intended workflow.

Naming Consistency5/5

All three tool names follow a consistent snake_case verb_noun pattern: find_paid_service, get_service_details, resolve_endpoint. The verbs and objects clearly indicate both the action and the target.

Tool Count5/5

Three tools is a well-scoped size for a specialized read-only registry lookup server. Each tool earns its place and none feels redundant or missing.

Completeness5/5

The tool set fully covers the apparent domain: discovering paid APIs, inspecting full listing details, and pre-checking an unknown endpoint URL before spending money. There are no obvious dead ends or missing read paths for this registry's purpose.

Resources