Skip to main content
Glama

brick.blue

by blue.brick
OverviewDiscussionsAdmin

Search agents

search_agents
Read-onlyIdempotent

Find agents and MCP servers that can do a task you describe in plain words. Use it whenever you need a capability you do not have; then get_agent for one result in full, or verify_endpoint when you already hold a URL. Ranked on what the hub measured — answers its checks, open, paid or key-required, price per call — not on what operators claim. Read-only, no account. Returns the matches with endpoints, tools, liveness and price, so you can pick one and call it.

Input Schema

NameRequiredDescriptionDefault
qNoWhat needs doing, in natural language or keywords
kindNoLimit to one protocol
limitNoMax results (default 7, best first). A longer shelf measurably worsens the pick and costs you the context, so ask for more only when you mean to read it; `hasMore` and `nextOffset` page the rest.
skillNoExact skill or tool name to require
accessNofree/open = the listing answered its handshake without asking for anything, which is what its card says rather than what its tools do. verified-open = this hub has called one of its tools and been served. Ask for verified-open when you need something you can use now; ask for open when you are surveying what is out there.
offsetNoWhere to resume — pass the `nextOffset` from the last answer
warningNonone = leave out listings whose text works on the agent reading it (posing as system instructions, demanding to be called first, pushing referral links…); any = only those; a kind = only that behaviour. Rows that have one carry it as `warning`.
categoryNoA topic, as `area` or `area/topic` (e.g. weather-and-environment/forecast); the listings carry theirs as `topic`. `suspicious` (or `suspicious/<kind>`, e.g. suspicious/poses-as-system) is the category of listings whose text works on the agent reading it
transportNoOnly listings served over this transport, e.g. streamable-http, sse or http

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / limit / minimum
      Added value: +0
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / offset / minimum
      Added value: +0
    • changedInput schema / properties / offset / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / transport
      Added value: +{
+  "description": "Only listings served over this transport, e.g. streamable-http, sse or http",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"A topic, as `area` or `area/topic` (e.g. weather-and-environment/forecast); the listings carry theirs as `topic`"New value: +"A topic, as `area` or `area/topic` (e.g. weather-and-environment/forecast); the listings carry theirs as `topic`. `suspicious` (or `suspicious/<kind>`, e.g. suspicious/poses-as-system) is the category of listings whose text works on the agent reading it"
  3. Changed1 schema field changed
    • addedInput schema / properties / warning
      Added value: +{
+  "description": "none = leave out listings whose text works on the agent reading it (posing as system instructions, demanding to be called first, pushing referral links…); any = only those; a kind = only that behaviour. Rows that have one carry it as `warning`.",
+  "enum": [
+    "none",
+    "any",
+    "poses-as-system",
+    "demands-priority",
+    "hides-from-user",
+    "extracts-data",
+    "self-propagates",
+    "affiliate-push",
+    "acts-unprompted"
+  ],
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / category
      Added value: +{
+  "description": "A topic, as `area` or `area/topic` (e.g. weather-and-environment/forecast); the listings carry theirs as `topic`",
+  "type": "string"
+}
  5. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, and 'Read-only' largely restates them. The description still adds real context beyond the structured fields: the ranking is based on what the hub actually measured (handshake answers, open/paid/key-required, price) rather than operator claims, and that no account is needed.

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 sentences, each doing distinct work: purpose, usage routing, ranking rationale, and return contents. Purpose and the sibling routing are front-loaded, and there is no 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?

There is no output schema, and the description compensates by naming what comes back ('endpoints, tools, liveness and price, so you can pick one and call it'). For a nine-parameter search tool, an agent has everything needed to call it and interpret the result.

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 coverage is 100%, so the schema already documents all nine parameters thoroughly, including the access enum and the paging contract. The description only gestures at the natural-language query ('a task you describe in plain words') and adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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?

States a specific verb ('Find') and resource ('agents and MCP servers') and the query mode ('a task you describe in plain words'). It explicitly distinguishes itself from siblings get_agent and verify_endpoint, so an agent can route without reading any schema.

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?

Gives an explicit trigger ('whenever you need a capability you do not have') and names the two alternative tools with the conditions that select them: get_agent for one full result, verify_endpoint when you already hold a URL. Nothing is left to inference.

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

All brick.blue 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