Skip to main content
Glama
Sign In

Callvu

by com.callvu
OverviewDiscussionsAdmin

Check if Callvu fits your process

assess_fit
Read-onlyIdempotent

Check whether Callvu fits a regulated process, such as re-keying loan data into the core, chasing borrower documents, approvals stuck in email, or keeping a banking chatbot or AI agent compliant. Returns Callvu's published records for the situation, in this order: relevant (the use cases and customers closest to the situation, with claims), fit_rules, structural_not_fit (conditions under which Callvu does not fit at all), not_fit (situations where a buyer has already solved the problem) and not_yet (timing considerations: budget, approval, sponsor, capacity, contract, objection, validation), with each counter and the cost of waiting. relevant.match_strength says how close the nearest use case is (strong, weak, none). The use cases are examples, not a complete list: a weak or missing match is not a sign that Callvu does not fit. Callvu runs no model on this request.

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": {
      "vertical": "<vertical>",
      "situation": "<situation>"
    },
    "name": "assess_fit"
  }
}

Input Schema

NameRequiredDescriptionDefault
verticalYesA vertical slug, name or alias, for example "banking", "Home lending" or "mortgage". Case-insensitive.
situationYesThe buyer's situation in their own words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes the important note that 'Callvu runs no model on this request' and that the returned use cases are illustrative rather than exhaustive. It does not add permissions, rate-limit or freshness details beyond that, so the extra value over the annotations is real but modest.

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?

The definition is front-loaded with the purpose and then lists the response ordering, which is genuinely useful given the absence of an output schema. It is dense with long compound sentences and the counter-list parenthetical is heavy, but nearly every clause carries information an agent needs.

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 no output schema, the description takes on the full burden of describing the return payload, and it does so completely: the five record groups in order, the meaning of relevant.match_strength, and the caveat about non-exhaustive use cases. An agent can interpret the result without further documentation.

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% and both parameters are required and documented, so the baseline is 3. The description refers to 'the situation' and 'the buyer's situation' but adds no syntax, format or validation detail beyond the schema, other than implicitly clarifying that the situation should be natural-language description.

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 uses a specific verb and resource ('Check whether Callvu fits a regulated process') and enumerates the concrete situations it covers (re-keying loan data, chasing borrower documents, approvals stuck in email, chatbot/AI-agent compliance). That framing is clearly distinct from siblings such as find_use_cases or compare_alternatives, which return use-case or comparison data rather than a fit verdict.

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 clear context for when to reach for this tool: a buyer with a regulated process who wants to know whether Callvu fits. It also warns that a weak or missing match in 'relevant' does not mean Callvu does not fit, which steers interpretation of the result. It stops short of naming when to prefer the sibling tools (e.g. find_use_cases, compare_alternatives) instead.

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

All Callvu toolsInspect
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