asksteps

asksteps: search the public documentation

asksteps_search_docs

Read-onlyIdempotent

Searches the public asksteps website and returns the matching passages with their URLs. Use it to quote or cite what the product actually does instead of describing it from memory, and to check whether a feature exists at all. An empty result means no page mentions the term — treat that as 'probably not a feature', not as 'search failed'; the note field says which of the two it is.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	What to look for, e.g. "PDF signature", "webhook", "custom domain".
`locale`	No	Preferred language of the page version, as an ISO 639-1 code such as "de" or "en". Pages that exist only in German are still returned.

Output Schema

TableJSON Schema

Name	Required	Description
`hits`	Yes	Matching passages, best match first. May be empty.
`note`	Yes	Set when the result needs explanation, e.g. when the documentation index is unavailable. Empty otherwise.
`query`	Yes	The query that was searched for.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds valuable behavioral context: it returns passages with URLs, and crucially, it clarifies that an empty result is not necessarily a failure and that a note field distinguishes the cases. This goes beyond the schema and annotations.

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?

The description is three sentences with no filler: it states the action, explains the purpose, and addresses the empty-result edge case. Every sentence adds information and the most important guidance is front-loaded.

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?

With only two parameters, a high-coverage schema, an output schema, and annotations for read-only and idempotent behavior, the description provides everything an agent needs to call this tool correctly. It even resolves a subtle ambiguity about empty results that would otherwise be easy to misread.

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 parameter descriptions already fully document both 'query' and 'locale'. The description provides an example query but does not add extra semantic explanation beyond what the schema already gives, so the baseline score of 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?

The description clearly states a specific verb ('Searches'), a resource ('the public asksteps website'), and the output ('matching passages with their URLs'). It also provides the intended use cases, making it obvious this is a documentation-search tool rather than a CRUD operation on forms or funnels.

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?

The description explicitly tells the agent when to use it: to quote or cite what the product does and to check whether a feature exists. It also explains how to interpret an empty result, saying it likely means the feature is absent rather than that the search failed, which is crucial practical guidance.

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

All asksteps tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Tools are mostly distinct with clear ownership of each resource and action, and descriptions explicitly contrast sibling pairs (analyze_pdf vs import_pdf, create_form vs create_funnel, publish_form vs update_publication, change_plan vs start_checkout). However, an agent skimming names alone could misselect between the four creation tools or the two PDF tools without reading the descriptions carefully.

Naming Consistency5/5

Every tool follows the asksteps_<verb>_<noun> pattern perfectly, with uniform verbs like get_, list_, create_, and update_. The only slight deviation is create_from_template, but even that stays predictable and readable within the convention.

Tool Count3/5

At 24 tools, this sits at the heavy end of the 16-25 borderline range. The broad domain (form/funnel building, publishing, PDF import, billing, stats, leads) justifies most of them and there is no obvious redundancy, but the sheer volume makes navigation harder than a tighter set.

Completeness4/5

The core form and funnel lifecycle is well covered: multiple creation paths, read, full replacement update, delete with confirmation, publish/unpublish, stats, and leads export. Billing covers first purchase, plan changes, and quota checks. Minor gaps exist — no dedicated subdomain listing tool, no funnel-specific stats, and no programmatic PDF field mapping — but these are explicitly documented as human steps, so agents can work around them.

Resources

Need Help?