Skip to main content
Glama

Find providers an unattended agent can actually finish with

find_providers
Read-onlyIdempotent

Describe the problem in your own words, for example "let users upload images" or "send transactional email". Returns the vendors we have measured in that category, split by whether an unattended run clears every barrier we test, stops at one, or was never measurable, each with the date and a link to the evidence. This is not a recommendation: it does not know whether a vendor suits your job, only where an agent stops. Routing a sentence to a category is by far the weakest thing here, and the numbers below are the ones to plan around. Measured on 40 questions written by an agent with no access to this repository and no sight of the category list, labelled before the first run, and built to be hard: fourteen of them ask about the caller own code in commercial words (a billing module, a payments table, a notifications worker), and six ask for something real that a catalogue this size does not hold. It got 29 of the 40 right, said nothing on 8 it should have answered, sent 0 to the wrong category and answered 3 that it should have refused. Put another way: it gave an answer to 14 of the 40, and 3 of those answers were wrong, while refusing 18 of the 21 it should have refused. It is deliberately quiet. One vocabulary word inside a long question decides nothing, and a question shaped like a request for code rather than for a vendor is refused outright. Silence means we could not read the question, not that the category is empty. The tool reads English. Name the category yourself when you know it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobYesThe problem to solve, in your own words.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate read-only and idempotent behavior, but the description adds substantial context: return format details, performance metrics from a benchmark, the deliberate quietness, refusal patterns, and the distinction between 'silence' and empty category. It goes far beyond what annotations provide and does not contradict them.

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

Conciseness2/5

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

While the description is front-loaded with the main instruction and return format, it quickly digresses into an extensive evaluation methodology discussion (40 questions, 29/40 accuracy, etc.). This is a wall of text that could be trimmed to the essential usage and behavioral notes. Every sentence does not earn its place.

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?

With no output schema, the description fully explains what the tool returns (vendors with date and evidence link, split by barrier status). It also covers input expectations, limitations, and how to interpret silence. It is complete enough for an agent to use correctly, even if overlong.

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

Parameters5/5

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

The schema has only a basic description for the 'job' parameter, but the tool description expands significantly: it gives examples, explains how to phrase problems, notes that English is expected, and clarifies how different input shapes are handled. This adds meaning well beyond the schema field.

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's function: it takes a free-text problem description and returns measured vendors in that category, split by barrier outcomes, with dates and evidence links. It explicitly distinguishes itself from a recommendation tool, clarifying its actual scope. The title and description are aligned.

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 provides explicit usage instructions: 'Describe the problem in your own words,' notes the tool reads English, and warns that silence means it could not read the question. It also specifies when not to use it ('This is not a recommendation') and suggests naming the category when known. This is comprehensive guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

The two tools have completely distinct purposes: find_providers accepts a problem description and returns vendor evaluation data, while scan_domain accepts a domain and returns HTTP check results. There is no overlap in input, output, or functionality, so an agent can easily distinguish them.

Naming Consistency5/5

Both tool names follow a clear verb_noun pattern with underscores (find_providers, scan_domain), which is consistent and predictable. There are no deviations or mixed conventions.

Tool Count3/5

With only two tools, the server's surface is thin. While each tool is detailed and serves a clear purpose, the server name 'Let Agents In' suggests a broader scope, making the count feel borderline for the implied domain.

Completeness2/5

The server covers only two specific evaluation tasks, leaving obvious gaps for a server that aims to 'let agents in.' Expected tools for access management, onboarding, or broader agent orchestration are missing, making the surface incomplete for the stated purpose.

Resources