EventTrader Research (read-only)

Agent Intake

agent_intake

Read-onlyIdempotent

START here when you are the user's own AI agent working with NEXUS. Record the owner's goal (amount, target, horizon, risk 1-5, interests, exclusions) in ONE call; anything you send is never asked again, anything missing takes a stated default (risk 3, 30 days). Returns the goal, the defaults used, at most three questions (only what cannot be defaulted) and a conversation_id. (no key needed)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "agent_intake"
  }
}

Input Schema

Name	Required	Description
`exclude`	No	tickers never to use
`symbols`	No	the owner's own picks — builds their own fund from exactly these
`interests`	No	themes, sectors, coins — optional
`risk_tier`	No	1 very low … 5 very high, or plain words ('conservative', 'aggressive'); default 3
`target_pct`	No	target return in percent
`asset_class`	No	Stocks, crypto, or both (the user's choice; one class = one vehicle).
`usdc_amount`	No	dollars of the owner's own money
`horizon_days`	No	days the owner can give it (default 30)
`conversation_id`	No	returned by the first call; send it on every turn

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the read-only/idempotent hints, it discloses defaults applied to missing input (risk 3, 30 days), the one-call capture contract ('anything you send is never asked again'), the return payload (goal, defaults used, at most three questions, conversation_id) and that no API key is required. The only tension is that 'Record ... never asked again' implies persisted state while readOnlyHint=true declares no state change; that is a wording ambiguity rather than a clear conflict, so it caps the score rather than invalidating it.

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 front-loaded with the entry-point cue and packs defaults, return contract and the no-key note into two sentences with no filler. The second sentence is a long run-on, and '(no key needed)' sits awkwardly at the tail where it is easy to miss.

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?

With nine all-optional parameters and no output schema, the description does the right work: it explains the return shape, the defaulting behavior and the conversation_id handoff, so the agent knows a sparse first call is legitimate. The one remaining gap is that the 'symbols builds their own fund' path is only documented in the schema, not surfaced here.

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?

Schema coverage is 100%, so the baseline is 3, but the description earns an extra point by naming defaults (risk 3, 30 days) and framing the 'at most three questions' fallback for anything that cannot be defaulted, which tells the agent it may call with a partial payload. It does not explain the symbols-vs-interests choice or the asset_class constraint, which live only in the schema.

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 gives a specific verb plus resource ('Record the owner's goal') and enumerates the payload the tool captures (amount, target, horizon, risk 1-5, interests, exclusions). The opening 'START here when you are the user's own AI agent' also positions it against the other agent_* siblings, so an agent can identify 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 Guidelines4/5

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

It states the triggering situation explicitly ('START here when you are the user's own AI agent working with NEXUS') and the conversation condition for repeat calls (send conversation_id on every turn). It stops short of naming a sibling or an exclusion case, so an agent still has to infer whether agent_propose_setup or ask_nexus should follow or precede it.

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

All EventTrader Research (read-only) 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?