Konexium

ask_konexium

Ask Konexium, a research service for African companies and markets, in plain language. It answers from company registers (GLEIF and national registries), sanctions and debarment lists, and the companies' own websites, and cites every source; what no source states is said plainly. Use it to check whether a company is real and active, screen it against sanctions lists, find companies that fit a brief, or watch a company for changes. Returns JSON {id, thread_id, status, output[]}. Each output item is a message (text with numbered [n] citations and their source URLs) or, when the request needs work that spends credits (a company search, a list check, monitoring or a data request), an approval_request with its id, label, credits and an approve_in_konexium link; status is then requires_approval. Nothing that spends credits runs until the person approves it in Konexium; to decline, call answer_ask_approval. Answers alone spend no credits but count toward the connection’s daily question limit.

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": {
      "question": "<question>"
    },
    "name": "ask_konexium"
  }
}

Input Schema

Name	Required	Description	Default
`question`	Yes	The question or request in plain language, for example "Is Safaricom PLC an active company in Kenya?". Name the company and its country when you know them.
`previous_response_id`	No	Optional. The id of an earlier ask_konexium response from this connection, to ask a follow-up in the same conversation. Omit it to start a new conversation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description carries real additional weight: it discloses the credit-cost gate, that nothing spending credits runs until the person approves in Konexium, the requires_approval status, and the daily question limit. That is exactly the behavioral context an agent needs before invoking this write-capable, open-world tool.

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 purpose, then use cases, then return shape and the approval/credits behavior — a logical order with no filler sentences. It is on the long side for a two-parameter tool, but the density is justified by the approval workflow it must convey.

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?

No output schema exists, yet the description defines the return shape ({id, thread_id, status, output[]}), explains both output item kinds (cited message vs. approval_request with id, label, credits, approve link), and ties status to requires_approval. Combined with the credit and rate-limit notes, an agent has everything needed to call it and interpret the result.

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 both the question format and previous_response_id follow-up semantics are already documented in the schema. The description reinforces the plain-language framing but adds no parameter meaning beyond that, which makes the baseline 3 correct.

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 opens with a specific verb and a named resource ('Ask Konexium, a research service for African companies and markets') and spells out the underlying data sources (GLEIF, national registries, sanctions lists, company websites). It also names the sibling 'answer_ask_approval' for the decline path, so an agent can tell the two apart without opening either schema.

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 four concrete use cases (verify a company is real and active, screen against sanctions, find companies fitting a brief, monitor for changes) and says which tool to use to decline an approval. Implicit scope restriction ('African companies and markets') is the only exclusion offered; there is no explicit statement of when not to use it.

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

All Konexium 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?