Search and run data, text, code, PDF and web APIs. Requests not stored. Network tools need a key.
Scored across 3 tools
The three tools have mostly distinct roles: list_categories enumerates the catalog structure, search_tools does keyword lookup, and run_tool executes. list_categories and search_tools both serve catalog browsing and could marginally overlap when an agent just wants to see what exists, but the descriptions make the boundary clear.
All three names follow a clean snake_case verb_noun pattern (list_categories, run_tool, search_tools). Consistent and immediately readable, with no mixed conventions.
Three tools is on the thin side but defensible for a thin gateway whose real surface is the external catalog it proxies. Each tool earns its place with no redundancy, though there is little room for anything beyond browse/search/execute.
The core meta-server lifecycle is covered: discover categories, search the catalog, and execute a tool with arguments, plus documented error statuses. A minor gap is the absence of a direct 'get tool details by exact name' or introspection/health tool, but search_tools largely compensates.
List tool categories with counts and example tool names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, not open-world). The description goes beyond them by disclosing what the operation actually returns — category names with counts and example tool names — which is meaningful given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the resource and the return shape packed in, and not a word of padding. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with full annotation coverage, the definition covers purpose and output content adequately. Minor gaps remain around ordering or pagination of categories, but these are unlikely to matter for a small static list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. This is the baseline case where no parameter guidance is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (List) and resource (tool categories) and even previews the return content (counts and example tool names). It is clearly distinguishable from run_tool and search_tools by its resource, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the discovery/browsing entry point before calling search_tools or run_tool, but the description states no when-to-use condition, no ordering relative to siblings, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a catalog tool by name with an arguments object. Returns the tool result and the external hosts contacted (usually none). Errors keep the HTTP status: 400 invalid input, 405 wrong method, 413 input over the size limit (files over 10 MB through MCP, JSON over 2 MiB), 422 a file that cannot be processed (for example an encrypted PDF), 429 quota used up.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Catalog tool name (e.g. "hash_text", "pdf_merge", "web_fetch") | |
| arguments | Yes | Tool arguments as key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the return payload (tool result plus external hosts contacted), and maps failure modes to HTTP semantics (400, 405, 413, 422, 429) with concrete size ceilings of 10 MB per file and 2 MiB of JSON. This is unusually rich behavioral context for a mutating, open-world tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, and the error enumeration is dense but each code carries distinct actionable meaning. Slightly list-heavy, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains the return value and error behavior, making it callable without further inference. It stops short of describing the nested arguments object's shape or how tool names are discovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds real constraint meaning to 'arguments' by specifying the 2 MiB JSON cap and the 10 MB per-file limit that shape what can legally be passed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Run a catalog tool by name with an arguments object.' This is clearly the execution counterpart to the discovery siblings list_categories and search_tools, though the description never explicitly names them to draw the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or prerequisite guidance; it never says the tool name must first come from search_tools/list_categories, nor when this is preferable to those siblings. Usage is only faintly implied by 'by name.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the tool catalog by keyword. Returns matching tool names, descriptions, parameters and a tested example argument object for each.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 10) | |
| query | Yes | Search keywords (e.g. "pdf merge", "sha256", "translate", "dns") | |
| category | No | Optional filter: compute, network, file, ai, or a category id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the return shape: names, descriptions, parameters, and a tested example argument object. That is genuine disclosure beyond the structured fields, though pagination/ordering behavior goes unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core action front-loaded and the return content following immediately. Nothing can be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly takes on the job of describing return values, which it does well for a simple three-parameter search tool. Minor gaps remain around result ordering and empty-result behavior, but nothing essential to invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented with examples and defaults. The description only restates the keyword concept and adds no format or filtering nuance beyond the schema, which is the baseline-3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Search the tool catalog by keyword') and clearly separates itself in function from list_categories (browse) and run_tool (execute). It stops short of explicitly naming or contrasting those siblings, so the differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by keyword' and the keyword examples in the schema, but there is no explicit statement of when to reach for this tool versus list_categories or run_tool, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
run_tool1 field changedInput schema / properties / tool / descriptionPrevious value: -"Tool name from search_tools (e.g. \"hash_text\", \"pdf_merge\", \"web_fetch\")"New value: +"Catalog tool name (e.g. \"hash_text\", \"pdf_merge\", \"web_fetch\")"search_tools1 field changedInput schema / properties / category / descriptionPrevious value: -"Optional filter: compute, network, file, ai, or a category id from list_categories"New value: +"Optional filter: compute, network, file, ai, or a category id"search_tools3 fields changedInput schema / properties / category / descriptionPrevious value: -"Optional category filter: compute, network, file, ai"New value: +"Optional filter: compute, network, file, ai, or a category id from list_categories"Input schema / properties / limitAdded value: +{
+ "description": "Max results (1-50, default 10)",
+ "type": "integer"
+}Input schema / properties / query / descriptionPrevious value: -"Search keyword (e.g. \"pdf merge\", \"hash\", \"translate\", \"dns\")"New value: +"Search keywords (e.g. \"pdf merge\", \"sha256\", \"translate\", \"dns\")"aes_decryptaes_encryptage_calcavatar_generatebarcode_generatebase64_decodebase64_encodebusiness_dayscidr_calccolor_blendcolor_contrastcolor_convertcolor_palettecredit_card_validatecron_parsecsv_to_jsondate_calculatedate_formatdetect_formatdns_lookupemail_validatefake_datagenerate_qrgenerate_uuidhash_texthashtag_generatehmac_signhtml_entities_encodehtml_minifyhtml_to_markdownhttp_status_infoiban_validateip_infoip_validatejson_diffjson_diff_detailedjson_flattenjson_formatjson_sort_keysjson_to_csharpjson_to_csvjson_to_gojson_to_javajson_to_kotlinjson_to_phpjson_to_pythonjson_to_rubyjson_to_rustjson_to_sql_createjson_to_swiftjson_to_typescriptjson_to_yamljson_validatekeyword_extractlanguage_detectlink_checklist_categorieslorem_ipsummarkdown_to_htmlmarkdown_to_textmath_factorialmath_fibonaccimath_gcdmath_is_primemath_percentagemeta_extractmeta_generatemorse_encodenumber_to_wordsotp_generatepassword_generatepassword_strengthphone_validatereading_timeregex_testrelative_timerobots_checkrobots_generaterot13run_toolsearch_toolssitemap_generatesql_formatssl_checktext_casetext_dedupetext_difftext_reversetext_sentimenttext_slugtext_to_markdowntext_truncatetimezone_convertunit_converturl_decodeurl_encodeurl_infourl_validateuuid_batchweb_fetchwhois_lookupword_countxml_to_jsonyaml_to_jsonaes_decryptaes_encryptage_calcavatar_generatebarcode_generatebase64_decodebase64_encodebusiness_dayscidr_calccolor_blendcolor_contrastcolor_convertcolor_palettecredit_card_validatecron_parsecsv_to_jsondate_calculatedate_formatdetect_formatdns_lookupemail_validatefake_datagenerate_qrgenerate_uuidhash_texthashtag_generatehmac_signhtml_entities_encodehtml_minifyhtml_to_markdownhttp_status_infoiban_validateip_infoip_validatejson_diffjson_diff_detailedjson_flattenjson_formatjson_sort_keysjson_to_csharpjson_to_csvjson_to_gojson_to_javajson_to_kotlinjson_to_phpjson_to_pythonjson_to_rubyjson_to_rustjson_to_sql_createjson_to_swiftjson_to_typescriptjson_to_yamljson_validatekeyword_extractlanguage_detectlink_checklorem_ipsummarkdown_to_htmlmarkdown_to_textmath_factorialmath_fibonaccimath_gcdmath_is_primemath_percentagemeta_extractmeta_generatemorse_encodenumber_to_wordsotp_generatepassword_generatepassword_strengthphone_validatereading_timeregex_testrelative_timerobots_checkrobots_generaterot13sitemap_generatesql_formatssl_checktext_casetext_dedupetext_difftext_reversetext_sentimenttext_slugtext_to_markdowntext_truncatetimezone_convertunit_converturl_decodeurl_encodeurl_infourl_validateuuid_batchweb_fetchwhois_lookupword_countxml_to_jsonyaml_to_json30+ web-access and AI APIs behind one key: search, scraping, browsers, voice, OCR and LLMs.
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
Web search, scraping, Google Trends and data lookups. Paid per call in USDC on Base via x402.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Add one secure layer between your agents and this server.