meta-agent-tools

MCP index search

mcp_index_search

Read-onlyIdempotent

Browse what independent MCP indexes measured, including servers this catalog does not list yet (casou=0). Newest change first. casou=0 is what the indexes know and the catalog does not — the list to look at before submitting a server. Filters are AND'd. With q, total is the exact number of matches, including when the requested page is empty.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Substring of name, URL or repository.
`casou`	No	1 matched to a listing, 0 not in the catalog.
`fonte`	No	One index: wellknown, agent_tools, nerq, truespar, neuronto, paygent, hultra.
`limit`	No	Signals per page, 1-50.
`estado`	No	vivo, fora, parado, abandonado, apagado, desconhecido.
`retry_key`	No	Optional retry key, up to 80 ASCII characters; same read for five minutes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

removedInput schema / properties / api_pass

Removed value: -{
-  "description": "MAT-only private pass: mat_<32 random hex>_<64 random hex>. Generate and save before buying.",
-  "type": "string"
-}

Changed2 schema fields changedSep 17, 2026

addedInput schema / properties / api_pass

Added value: +{
+  "description": "MAT-only private pass: mat_<32 random hex>_<64 random hex>. Generate and save before buying.",
+  "type": "string"
+}

addedInput schema / properties / retry_key

Added value: +{
+  "description": "Optional retry key, up to 80 ASCII characters; same read for five minutes.",
+  "type": "string"
+}

AddedSep 17, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real behavior: result ordering (newest change first), AND-combined filters, and the guarantee that with q the total is the exact match count even when the page is empty. It omits anything about the shape of a returned 'signal', but the added ordering and total semantics are substantive.

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

Conciseness4/5

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

Front-loads the core scope and keeps to four short sentences with no filler. The casou=0 concept is explained twice (once parenthetically, once in full), which is mild redundancy but the rest earns its place.

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 output schema and no required parameters, the description carries the ordering, filter logic and total semantics an agent needs to query correctly, and annotations cover safety. What a 'signal' record contains is left unspecified, which is the main remaining gap.

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?

Schema description coverage is 100%, so the per-parameter baseline is 3; the description exceeds it by explaining the cross-parameter semantics (filters AND'd) and clarifying casou=0 as the catalog-miss case rather than just repeating the enum label. It still adds nothing for retry_key or limit beyond the schema.

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?

States a specific verb and resource ('Browse what independent MCP indexes measured') and scopes it to servers the catalog does not list, which distinguishes it from catalog-listing siblings like list_mcp_servers and mcp_index_signals. It does not name any sibling explicitly, so an agent must infer the boundary rather than being told.

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?

Gives a concrete use case: 'the list to look at before submitting a server' for casou=0, and states that filters are AND'd, which tells the agent how to combine them. No explicit when-not-to-use or named alternative tool is offered, so it stops short of a 5.

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

All meta-agent-tools tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?