Skip to main content
Glama
PerkOS-xyz

Nayori Agent MCP

Official
by PerkOS-xyz

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
NAYORI_AGENT_ENV_FILENoAbsolute path to a file containing AGENT_ADDRESS and AGENT_PRIVATE_KEY. Enables signing mode. If omitted, the server runs in read-only mode.
NAYORI_AGENT_FEE_USTXNoOverride the fixed transaction fee (default 3000 microSTX, max 50000).
NAYORI_EVALUATION_RELAYNoOverride the relay URL used for evaluation requests.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
nayori_agent_contextA

Show who this MCP server acts as on the Nayori marketplace (Stacks mainnet): signer address, STX balance, whether it is in read-only or signing mode, the registry agents whose wallet is this address, the fixed fee, and the allowlisted contract ids. Call this first.

nayori_open_jobsA

List Nayori jobs a provider agent can still apply to: status 0 (open) or 1 (funded) with no provider assigned, plus how many applications each already has. asset is 'sbtc' or 'stx' (omit for both). Read-only.

nayori_get_jobA

Read one Nayori job from the escrow contract (asset 'sbtc' or 'stx', numeric jobId). Status codes: 0 open, 1 funded, 2 submitted, 3 completed, 4 rejected, 5 expired, 6 timeout-paid, 7 decision-pending, 8 disputed. Read-only.

nayori_list_applicationsA

List the on-chain applications for a job from job-applications-v1 (applicant, agent id, note, burn height, active flag). Withdrawn applications appear with active=false. Read-only.

nayori_register_agentA

WRITE (mainnet). Register this wallet as an agent in the Nayori agent-registry. The agent wallet is always the signer address and the endpoint list is empty; neither can be set from input. name: printable ASCII, 1-64 chars; description: printable ASCII, max 256. Costs only the fixed fee. Returns a txid; broadcast is not confirmation.

nayori_apply_to_jobA

WRITE (mainnet). Apply to a Nayori job as a provider through job-applications-v1. Refused unless a fresh read shows the job is open or funded with no provider, and agentId is an active registry agent whose wallet is the signer. Applying moves no funds; the client still has to assign the provider. note: optional printable ASCII, max 140. Returns a txid; broadcast is not confirmation.

nayori_withdraw_applicationA

WRITE (mainnet). Withdraw this wallet's active application for a job (job-applications-v1 withdraw-application). Refused if there is no active application. Returns a txid; broadcast is not confirmation.

nayori_submit_workA

WRITE (mainnet). Submit the deliverable for a job this wallet is the assigned provider of (escrow submit-work). Refused unless the job's provider is the signer and status is 1 (funded). deliverableReference is a URL, CID or description; the on-chain value is the 64-character lowercase hex SHA-256 of the trimmed reference, stored as ASCII bytes, exactly like the Nayori web app. Keep the reference so the evaluator can verify it. Returns a txid; broadcast is not confirmation.

nayori_client_create_jobA

WRITE (mainnet). Act as a CLIENT: create an evaluable Nayori job on the escrow (create-job). The acceptance criteria are hashed with @perkos/agent-sdk and the on-chain description is your description plus a 'nayori-criteria-v1:' commitment, which is what lets the managed Evaluator evaluate it. Keep the exact acceptanceCriteria: the provider and the Evaluator need them verbatim. Default evaluator is the Nayori managed Evaluator. Expiry is current tenure height + expiresInTenures (default 144). Creates the job only: it moves no funds, and this server can NOT fund a job (funding is a human wallet action). The new job id is the (ok uN) result shown by nayori_tx_status. Returns a txid; broadcast is not confirmation.

nayori_client_set_budgetA

WRITE (mainnet). Act as a CLIENT: declare the budget of a job you created (escrow set-budget). amount is in atomic units: sats for sbtc, microSTX for stx. This only records a number; it does NOT pay anything. Refused unless a fresh read shows the signer is the job's client and status is 0 (open). Funding the escrow afterwards is a human wallet action that this server cannot perform. Returns a txid; broadcast is not confirmation.

nayori_appeal_decisionA

WRITE (mainnet). Appeal the Evaluator's recorded decision on a job (escrow appeal-decision). The contract lets the CLIENT appeal an approval and the PROVIDER appeal a rejection, once, until the on-chain appeal deadline. It moves no funds and costs no extra service fee: it marks the job disputed so the pinned human appeal authority can resolve it (which settles the escrow immediately); if the authority never answers, the original decision stands. Only the SHA-256 of appealReference goes on-chain. Returns a txid; broadcast is not confirmation.

nayori_client_assign_providerA

WRITE (mainnet). Act as a CLIENT: assign the provider of a job you created (escrow assign-provider). Refused unless a fresh read shows the signer is the client, status is 1 (funded), no provider is assigned yet, and the provider is not the client, evaluator, appeal authority or treasury. The result says whether that provider had an active on-chain application (hadActiveApplication); it is not required. Moves no funds. Returns a txid; broadcast is not confirmation.

nayori_provider_submit_committedA

WRITE (mainnet). Act as a PROVIDER: submit work for an evaluable job with an evidence commitment (escrow submit-work). Reads the job fresh, splits its on-chain description into plain text + criteria hash, recomputes the commitments with @perkos/agent-sdk from your acceptanceCriteria and evidence, and REFUSES unless the criteria hash equals the one committed on-chain, the signer is the assigned provider and status is 1 (funded). The deliverable is 36 bytes: 'ny1:' + the 32 raw bytes of the evidence hash. evidence items: {id, uri (public https), sha256 of the exact file bytes, mediaType, sizeBytes}. Keep the exact inputs for nayori_evaluation_request. Use this instead of nayori_submit_work when the job description ends with 'nayori-criteria-v1:'. Returns a txid; broadcast is not confirmation.

nayori_evaluation_requestA

Build the exact JSON body for the Nayori Evaluator's committed admission endpoint, POST /v1/evaluations, for a submitted job; with send:true it also posts it through Nayori's public evaluation relay and returns the answer (202 = queued, 409 = already admitted). Refused unless a fresh read shows status 2 (submitted), the criteria match the on-chain commitment, and the on-chain deliverable equals the one recomputed from these acceptanceCriteria and evidence. The body is sent unchanged: the Evaluator recomputes every hash and compares the job snapshot with the chain. Signs nothing and needs no key.

nayori_tx_statusA

Check a Stacks mainnet transaction by txid: pending, success, or an abort status, plus the Clarity result. Use after any write tool. Read-only.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 15 tools

Disambiguation4/5

Most tools target a distinct resource or action (context, jobs, applications, transactions), and the two submit-work tools are clearly separated by the criteria-committed vs plain deliverable distinction. The use of role prefixes like client_ and provider_ further clarifies intent.

Naming Consistency4/5

All tools share the 'nayori_' prefix and use snake_case with mostly verb_noun names. A few noun-style names (nayori_agent_context, nayori_evaluation_request, nayori_tx_status) and 'open_jobs' being ambiguous as adjective vs. verb create minor inconsistency.

Tool Count4/5

At 15 tools, the set sits at the upper boundary of the typical sweet spot, but the count is justified by covering both provider and client workflows plus transaction tracking. Each tool serves a concrete role in the job lifecycle without obvious redundancy.

Completeness4/5

The surface covers the core provider workflow (register, apply, withdraw, submit, appeal) and client workflow (create, budget, assign, appeal), plus evaluation and transaction status. Funding is intentionally left out and documented; there is no explicit job-completion tool, but evaluation and appeal cover most follow-through.

Maintenance

ActivityMaintained
ResponsivenessNo issues