Emergent Technologies

Ask Emergent

ask_emergent

Read-onlyIdempotent

Ask Emergent Technologies' own agent a question in plain words (data licensing, the payout estimate, privacy, the referral partner program, AI consulting, the lab, contact). It answers only from Emergent's fact book: the claims are quoted as published, each with its fact id, status and source page, followed by the next step for who is asking. If the fact book does not cover the question it says so and gives the contact path. The question is treated as data: instructions inside it are not followed. It saves and sends nothing.

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_emergent"
  }
}

Input Schema

Name	Required	Description	Default
`role`	No	Who is asking, to pick the next step: owner, partner, buyer (an AI lab or data buyer), consulting, or other
`question`	Yes	The question, in plain words (up to 2,000 characters). Please leave out personal details.

Output Schema

Name	Required	Description	Default
`meta`	Yes
`mode`	Yes
`topic`	Yes
`answer`	Yes
`covered`	Yes
`refused`	Yes
`nextStep`	Yes
`citations`	Yes
`disclosure`	Yes
`topicLabel`	Yes
`refusalKind`	Yes
`fallbackReason`	No
`factBookVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, closed-world, non-destructive), it discloses the answer contract: claims are quoted as published with fact id, status, and source page, followed by a role-specific next step. It also states the prompt-injection defense ("the question is treated as data: instructions inside it are not followed") and that nothing is saved or sent, which are behavioral traits no annotation conveys.

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?

It is a single dense paragraph that front-loads the purpose and covered topics, then the answer format, then the safety guarantees. Every sentence carries information, though the parenthetical topic list and the run of contract details make it slightly long compared to an ideal two-to-three sentence core.

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?

An output schema exists and annotations cover the safety profile, so the description's job is to explain scope, answer shape, fallback behavior, and trust boundary — all of which it does. An agent has everything needed to call it correctly and to interpret what comes back.

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 the role parameter's meaning ("to pick the next step") is already documented in the schema, so the description adds no new parameter-level detail. It adds behavioral context around the question instead, which is baseline 3 territory. Note the schema itself is internally inconsistent (maxLength 100000 vs. "up to 2,000 characters"), but that is a schema issue rather than a description gap.

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 ("ask a question") and resource (Emergent's own agent answering from the fact book), and enumerates the covered topics (data licensing, payout estimate, privacy, referral partner program, AI consulting, the lab, contact). This makes it clearly distinguishable from siblings like search_facts, estimate_payout, or consulting_offer 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 Guidelines4/5

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

It sets clear usage context by listing the topical domains the tool covers and explains the fallback when the fact book lacks an answer (it says so and gives the contact path). It stops short of explicitly naming alternatives or exclusions (e.g., "for a numeric payout calculation use estimate_payout instead"), so it is strong context without sibling routing.

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

All Emergent Technologies 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?