7IT Solutions

Find an MCP tool for a job (7Maps)

find_tool

Read-onlyIdempotent

Use this when you need a tool for a job and do not know which MCP server has one: searches every tool of every public MCP server on the 7Maps map (over 200,000 tools, probed daily) and returns the best matches with an automated estimate of what each tool can do (read-only, changes data, high risk), whether its server is answering now, its handshake time, the tokens its tool list costs to load, and a page to check it. Filter to read-only tools, servers answering now, a latency or token ceiling. Copies of the same tool on several servers are collapsed. No charge. To have 7Maps pick one server and tool for you with alternatives, use route.

Input Schema

TableJSON Schema

Name	Required	Description
`job`	Yes	What the tool should do, in plain words, for example "send a transactional email" or "query a postgres database"
`may`	No	What the tool may do: read = read-only only; change = read or change data; any = include high-risk tools (default any)
`limit`	No	How many results (default 10)
`payment`	No	Payment terms: any (default); free_only = only servers that declare no payment; paid_ok = servers that charge are fine, servers whose payment terms are unknown are left out. Paid servers show their declared price per call.
`answering_now`	No	Only servers that answered with tools on the last check (default true)
`max_handshake_ms`	No
`max_tool_list_tokens`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`matched`	Yes
`results`	Yes
`tools_indexed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / payment

Added value: +{
+  "description": "Payment terms: any (default); free_only = only servers that declare no payment; paid_ok = servers that charge are fine, servers whose payment terms are unknown are left out. Paid servers show their declared price per call.",
+  "enum": [
+    "any",
+    "free_only",
+    "paid_ok"
+  ],
+  "type": "string"
+}

AddedOct 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and non-open-world, so the safety question is covered. The description still adds real behavioral context: results carry an automated capability/risk estimate, live server reachability, handshake latency, tool-list token cost, duplicate tools across servers are collapsed, and it is free. It stops short of describing result shape or pagination, though an output schema exists.

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?

Usage condition and core behavior are front-loaded, and the closing sentence routes to the alternative. The opening sentence is long and clause-heavy, packing scope, outputs and filters into one breath, but almost every clause carries information an agent needs.

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?

For a 7-parameter search tool with an output schema, the description covers scope, trust signals, dedup, cost and the sibling alternative. Remaining gaps are minor: how payment terms surface in results and the interaction between the default filters (answering_now true, may any) are left to the schema.

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 71%, and the description gestures at the filter set ('read-only tools, servers answering now, a latency or token ceiling') without adding syntax or semantics for max_handshake_ms, max_tool_list_tokens or limit. Payment filtering is only implied by 'No charge'. The schema carries most of the parameter meaning, so a baseline 3 fits.

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 states a concrete verb and resource ('searches every tool of every public MCP server on the 7Maps map') and quantifies scope with 'over 200,000 tools, probed daily'. It also explicitly distinguishes itself from the sibling 'route', which picks a server for you instead of returning ranked matches.

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?

It opens with the exact triggering condition ('when you need a tool for a job and do not know which MCP server has one') and closes with the alternative and the condition that selects it ('To have 7Maps pick one server and tool for you with alternatives, use route'). Both when-to-use and when-to-use-something-else are stated.

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

All 7IT Solutions 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?