resolveFree exploratory discovery. Use only when browsing possible tools/APIs/MCP services without needing a trustworthy execution choice yet. For an actual missing capability, prefer procure so required evidence fails closed and unresolved candidates can escalate to verification.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| goal | Yes | ||
| limit | No |
Changes observed during successful MCP inspections.
Input schema / properties / goal / descriptionRemoved value: -"Plain-language description of the missing capability."Input schema / properties / goal / maxLengthRemoved value: -1000Input schema / properties / limit / descriptionRemoved value: -"Maximum results per discovery source. Defaults to 3."Input schema / properties / url / descriptionRemoved value: -"Optional public URL related to the task when discovery should consider a concrete endpoint or resource."Input schema / properties / goal / descriptionAdded value: +"Plain-language description of the missing capability."Input schema / properties / goal / maxLengthAdded value: +1000Input schema / properties / limit / descriptionAdded value: +"Maximum results per discovery source. Defaults to 3."Input schema / properties / url / descriptionAdded value: +"Optional public URL related to the task when discovery should consider a concrete endpoint or resource."Input schema / properties / goal / descriptionRemoved value: -"The missing capability in plain language, including useful constraints. Examples: 'verify this MCP endpoint and list its tools'; 'audit this website for agent discoverability'; 'render a JavaScript page and extract structured product data'."Input schema / properties / limit / descriptionRemoved value: -"Maximum ranked matches per result group. Omit for the default of 3."Input schema / properties / url / descriptionRemoved value: -"Optional target URL if the task concerns a specific web resource."Input schema / properties / goal / descriptionPrevious value: -"The missing capability in plain language, including useful constraints. Examples: 'render a JavaScript page and extract structured product data'; 'transcribe an audio URL'; 'find an API for company enrichment'."New value: +"The missing capability in plain language, including useful constraints. Examples: 'verify this MCP endpoint and list its tools'; 'audit this website for agent discoverability'; 'render a JavaScript page and extract structured product data'."Input schema / properties / goal / descriptionAdded value: +"The missing capability in plain language, including useful constraints. Examples: 'render a JavaScript page and extract structured product data'; 'transcribe an audio URL'; 'find an API for company enrichment'."Input schema / properties / limit / descriptionAdded value: +"Maximum ranked matches per result group. Omit for the default of 3."Input schema / properties / url / descriptionAdded value: +"Optional target URL if the task concerns a specific web resource."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds usage boundaries but little behavioral detail such as what kind of results are returned or how candidates are represented. No contradiction with annotations.
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?
The description is short, front-loaded with the core purpose, and every sentence earns its place. It communicates the use boundary and alternative in two compact sentences without repetition.
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?
Given the rich annotations and simple schema, the description is adequate for tool selection but not fully complete for invocation. It omits output/return expectations and any guidance on how url or limit shape the discovery, so an agent may still guess about parameter usage.
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 0%, so the description must compensate for parameter meaning, but it does not. It never explains the required goal parameter or the optional url and limit parameters, leaving their roles and expected values under-specified.
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 purpose: free exploratory discovery for browsing possible tools/APIs/MCP services without needing a trustworthy execution choice. It clearly distinguishes itself from procure, which is for actual missing capabilities.
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?
It explicitly says when to use this tool (browsing/exploration only) and when not to use it, directing agents to procure for actual missing capabilities. This provides a clear decision rule against an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.