Skip to main content
Glama
Parmasanandgarlic

FarmDash Agent OS

by Parmasanandgarlic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

agent_onboard

Read-onlyIdempotent

Initialize an agent session by fetching live feature readiness, tier gates, error semantics, execution-mode choices, and the onboarding capability map before tool selection.

Instructions

[Capability: available; tier: scout; API: /api/v1/agent/status; authority: /api/v1/agent/status] First-run contract: fetch live feature readiness, tier gates, error semantics, execution-mode selection (USER_SIGNED default vs opt-in BOUNDED_AUTONOMOUS), and the onboarding capability map before selecting tools. Before entering any wallet-changing execution workflow, query current execution authority with get_execution_authority for the active persisted FarmDash session: if an active valid bounded delegation already exists for that session, report its policy bounds instead of re-prompting; a different/new agentSessionId does not inherit another session’s grant and remains USER_SIGNED (Standard FarmDash), and you must explicitly obtain user choice/consent before requesting a one-time scoped delegation for BOUNDED_AUTONOMOUS (Autonomous FarmDash, EOA_V1_OWNER_LOCAL_SIGNER where sessionPublicKey == ownerAddress). This never enables execution. Takes no parameters.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv5.0.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false; the description usefully reinforces this with 'This never enables execution' and 'Takes no parameters,' which is exactly the safety clarification an agent needs before a first-run call. It stops short of describing the response shape, but the key behavioral boundary is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph where roughly two-thirds of the content is an extended instruction about get_execution_authority, delegation inheritance, and consent flow rather than this tool. The genuinely relevant sentences (first-run contract, what it returns, takes no parameters) are buried among bracket metadata and off-tool policy prose.

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 no output schema, the description does enumerate what comes back (feature readiness, tier gates, error semantics, execution-mode options, capability map), which is what an agent needs to decide to call it first. The extra delegation narrative is unnecessary but does not leave a functional gap.

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?

Zero-parameter tool, so the baseline is 4, and the description confirms 'Takes no parameters,' which is consistent with the empty schema and additionalProperties=false. Nothing further is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: fetch live feature readiness, tier gates, error semantics, execution-mode selection, and the onboarding capability map, framed as a 'first-run contract.' This is distinguishable from siblings like get_execution_authority or get_agent_performance, though the embedded metadata prefix ('[Capability: available; tier: scout; API: ...]') adds noise rather than clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Explicitly says to call it 'before selecting tools,' which is real when-to-use guidance. However, the majority of the text is guidance about a different tool (get_execution_authority) and delegation policy, with no stated when-not-to-use or alternatives for this tool itself, so the routing signal is muddied rather than sharpened.

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

Deploy Server

Other Tools