Retrieves the shared farming context for an active agent session so AI agents can access session-scoped state and status before coordinating DeFi actions.
[Capability: available_with_tier_gate; tier: pioneer_plus; API: /api/v1/agent/context; authority: /api/v1/agent/status] Read the shared FarmingContext for a live agent session.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| agentAddress | Yes | ||
| sessionToken | Yes |
Changes observed during successful MCP inspections.
v5.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description does add meaningful context the annotations lack: a tier gate (pioneer_plus) and the backing API/authority endpoints. It still does not describe the shape of the returned FarmingContext or session requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the capability metadata front-loaded. The bracketed capability/tier/API prefix is arguably overhead, but it is at the start and short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 says nothing about what fields a FarmingContext contains or what errors occur when the tier gate is not met. Combined with zero parameter documentation and no guidance against patch_farming_context, an agent cannot reliably call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all three required parameters (sessionId, agentAddress, sessionToken) are undocumented. The description only implies a session via 'live agent session' and gives no explanation of what a session token is or how agentAddress is formatted, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read the shared FarmingContext for a live agent session.' However, it does not distinguish itself from the obvious sibling patch_farming_context, which an agent could easily confuse with this read path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The sibling set includes patch_farming_context and get_execution_authority, and the description never says which one an agent should reach for under what conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.