Evolc Signals

Check my accounts

check_accounts

Read-only

Check a list of known companies (e.g. the user's CRM accounts or target list, up to 100 per call): which are hiring, raised money or grew in the window, and which are quiet. Matching is exact by domain (website URL or e-mail address at the company also works), else by name within a country, else by a unique name; name matches are marked. The list is used only to answer this call.

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": {
      "accounts": "<accounts>"
    },
    "name": "check_accounts"
  }
}

Input Schema

Name	Required	Description
`days`	No	Look-back window in days.
`subs`	No	Sub-roles within the chosen families.
`kinds`	No	Signal kinds that count (default: all).
`accounts`	Yes	Companies to check, each with a domain or a name.
`families`	No	Only signals and open roles in these job functions.
`exclude_volume`	No	Leave out volume hirers (staffing agencies, branch and field-sales networks).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), yet the description adds real behavior: the matching precedence chain (exact domain first, then name within a country, then unique name), the fact that name matches are flagged, the 100-account ceiling, and a data-handling promise that the list is used only for this call. It stops short of describing rate limits or the response payload.

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?

A single tight block with the main purpose front-loaded and no filler; the cap, matching rules and privacy note all earn their place. The matching-priority sentence is a long run-on that takes a second read to parse.

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 six-parameter, read-only batch lookup with no output schema, this covers purpose, input shape, matching semantics and retention. The one meaningful gap is the response shape beyond the four headline states (per-account grouping, unmatched accounts, how 'name match' is marked).

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 description coverage is 100%, so the per-parameter documentation is already handled by the schema (including the domain/URL/e-mail equivalence and the country code narrowing names). The description's added value is the precedence order among domain, country and name, which the schema does not state — useful, but a modest increment over an already-complete schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check a list of known companies ... up to 100 per call') and summarizes the answer shape (hiring / raised money / grew / quiet). This clearly reads as a batch lookup over known accounts, implicitly distinct from single-company siblings like get_company, but no sibling is named so the differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the tool is for a caller who already holds a CRM/target list and wants signals on it, and the 'up to 100 per call' cap hints at batching. There is no explicit when-to-use versus search_signals or get_company, and no stated handling for accounts that produce no match.

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

All Evolc Signals 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?