SiteCheck Company Records

Clio App Directory, one page of 9: app slug, name, one-line

b2b_clio_app_directory

Read-only

Clio App Directory (integrations for Clio legal practice-management software), one page of 9: app slug, name, one-line description, listed price (as shown, e.g. $50/month or Free), logo and app page link, plus the total page count. From clio.com/app-directory via a residential proxy. Related tools on this server, for a different need: b2b_apis_guru_openapi_directory when you need APIs.guru open directory of public API descriptions: finds; b2b_doabooks_directory_open_access when you need Peer-reviewed open access books from DOAB, the Directory. Price: $0.01 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "b2b_clio_app_directory"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Directory page 1-60 (default 1)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the data source (clio.com/app-directory), that access is via a residential proxy, the pagination model (9 items per page plus a returned total page count), and the billing model (x402 payment on Base/Solana/Arc, failures not charged). What is missing is any note on rate limits, proxy failure behavior, or freshness of the scraped data.

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

Conciseness3/5

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

The core content is front-loaded and the source/cost details are useful, but the sibling-routing sentence is long, awkwardly punctuated and partly malformed, reading more like stitched-together boilerplate than a clean pointer. The pricing sentence is fixed boilerplate across the server but takes a full third of the text.

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 one optional parameter at full schema coverage, read-only/open-world annotations, and an output schema that defines return values, the description only needs to cover source, scope, pagination and cost — and it does all four. Nothing an agent needs in order to invoke this correctly is absent.

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 coverage is 100% and the single parameter already documents the 1-60 range and default, so the baseline would be 3. The description still adds meaning beyond the schema by stating the page size is 9 items and that the response includes a total page count, which is what an agent needs to plan pagination.

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 first sentence names the specific resource (Clio App Directory integrations for legal practice-management software), states it returns one page of 9 items, and enumerates the exact fields returned (slug, name, one-line description, price, logo, link, total page count). It also names the two sibling directories it is not, so an agent can distinguish it without opening schemas.

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?

It gives explicit routing conditions for alternatives — b2b_apis_guru_openapi_directory for public API descriptions and b2b_doabooks_directory_open_access for DOAB open-access books — which is real when-to-use guidance. The routing clauses are terse and slightly garbled ("open directory of public API descriptions: finds;"), and there is no explicit statement of when *not* to use this tool beyond the implicit legal-software domain.

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

All SiteCheck Company Records tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?