Argorant

Quick search by company or words

search

Read-onlyIdempotent

Count how many people Argorant has for one company domain or a few plain words, and get result ids to open with fetch. Use it for simple questions such as how many people work at one company. For any search with job titles, places, industries or exclusions, use argorant_count_people for the number or argorant_preview_people for example rows instead. When the text holds a domain, only the domain is used. It shows no contact details, costs no credits and counts toward a free daily safety limit. Returns the count and up to two result ids for fetch. More in the docs at https://docs.argorant.com/docs/agents/tools#read-and-preview

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	A company domain such as linfieldhq.com, or a few plain words such as dental clinics. Job titles, places and other filters are not read here.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world) the description adds real context: no contact details are shown, no credits are consumed, it counts against a free daily safety limit, and a domain in the query suppresses all other terms. That is meaningful disclosure about cost and rate ceilings. It stops short of describing anything about the returned row shape beyond 'count and up to two result ids', leaving fetch to explain the rest.

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?

Front-loaded with the core action and the routing rule in the first three sentences, so a skimming agent still gets the essentials. It runs slightly long, and the trailing documentation URL plus a repeated mention of fetch (also stated earlier) cost a little tightness, but nearly every sentence carries a distinct constraint.

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?

For a one-parameter read tool with an output schema and full annotation coverage, the description covers the input forms, the domain-only edge case, cost and rate-limit implications, the return payload size, and the sibling alternatives. Nothing an agent needs to call it correctly is missing.

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?

The single parameter is fully documented in the schema (100% coverage), so the baseline is 3. The description adds a rule the schema does not state as clearly: 'When the text holds a domain, only the domain is used,' which tells the agent that mixed domain-plus-keyword input is silently narrowed rather than combined.

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?

States a specific verb and resource ('Count how many people Argorant has') plus the two accepted input forms (one company domain or a few plain words), and explicitly positions itself against argorant_count_people and argorant_preview_people so an agent can pick it without opening any schema.

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?

Gives a positive usage rule ('Use it for simple questions such as how many people work at one company') and an explicit exclusion with named alternatives: any search with job titles, places, industries or exclusions must go to argorant_count_people or argorant_preview_people. Both the when-to-use and when-not-to-use conditions are spelled out.

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

All Argorant 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.