MCP Tools, Resources, Apps, and Tasks

Draft 0.1 — 2 August 2026
ANUKA adopts MCP as an agent-facing integration protocol, not as a replacement for core authorization, business APIs, audit records, or human approval.

Objective

MCP gives AI hosts a common way to discover and invoke tools and retrieve resources. ANUKA uses it to make network capabilities available across compatible assistants and agent runtimes without creating a separate proprietary agent API for every host.

The rule is:

MCP exposes ANUKA capabilities; it does not create ANUKA authority.

Selected protocol baseline

The current reference baseline is MCP protocol revision 2026-07-28.

That revision defines:

stateless, self-contained requests;
per-request capability negotiation;
server discovery;
tools, resources, and prompts;
elicitation;
optional extensions;
Tasks for asynchronous work;
Skills over MCP;
MCP Apps;
authorization and deprecation mechanisms.

The exact SDK versions and supported extensions require an ADR and conformance tests before production release.

ANUKA MCP topology

Shared Core MCP Gateway

Exposes network-level capabilities such as:

product and capability discovery;
public documentation resources;
opportunity search;
Passport presentation requests;
consent status;
contribution drafts;
evidence validation;
governance records;
conformance checks.

Resident Product MCP Server

A product may expose product-specific tools and resources under its own operator, terms, policies, and availability.

The product must declare whether its server is:

operated by the resident product;
operated by ANUKA as a shared service;
operated by a third party;
self-hosted by the user.

Local MCP Server

Used for local repository, development, CLI, or private data workflows.

Local execution does not automatically make a tool safe. File, shell, credential, and network access remain high-risk capabilities.

Server identity

Each MCP server registration includes:

stable server ID;
operator;
product and organization scope;
canonical endpoint;
supported protocol revisions;
supported extensions;
authorization metadata;
tool and resource namespaces;
data classification ceiling;
privacy and retention policy;
support and security contact;
artifact digest or deployment evidence where practical;
status: draft, verified, suspended, retired.

A URL alone is not sufficient server identity.

Discovery

Discovery may occur through:

ANUKA capability registry;
product Presence manifest;
MCP server discovery method;
trusted host configuration;
local configuration;
organization-managed catalog.

Discovery records must preserve operator and trust status.

A community-listed server must not be presented as Foundation-verified without verification.

Namespaces

Tool and resource names should use stable namespaces.

Examples:

anuka.product.get
anuka.opportunity.search
anuka.contribution.draft
anuka.evidence.validate
anuka.consent.request
anuka.governance.proposal.compare

Resident products may use:

product.<product-slug>.<capability>

Names are aliases to versioned contracts, not the only identity of a tool.

Tool metadata

Every ANUKA tool definition includes or resolves:

tool contract ID;
version;
title and description;
input JSON Schema;
output JSON Schema;
required capability;
risk tier;
data classification;
read-only status;
idempotency;
external side effects;
destructive behavior;
approval mode;
estimated cost or budget class;
timeout;
operator;
deprecation status.

Tool annotations are advisory to the model and host. Server-side policy remains authoritative.

Input schemas

MCP tool inputs use full JSON Schema Draft 2020-12 as supported by the selected MCP revision.

Schemas must bound:

string and array sizes;
nesting depth;
formats;
allowed properties;
external references;
URLs and origins;
monetary amounts;
file references;
recipient lists;
tool-specific extension points.

Implementations must not automatically dereference arbitrary external $ref URLs from untrusted schemas.

Output schemas

Tools should provide output schemas whenever the result is machine-consumed.

Outputs distinguish:

human-readable summary;
structured content;
resource references;
warnings;
evidence references;
side-effect status;
retryability;
approval or follow-up requirements.

A successful protocol response does not necessarily mean the business outcome succeeded. The structured result must state the domain status.

Tool execution profile

For every call, the gateway:

authenticates client and principal;
validates protocol revision and headers;
resolves server and tool version;
validates input schema;
evaluates authorization and consent;
evaluates incident restrictions;
determines approval requirement;
executes with scoped credentials;
validates output;
records audit and telemetry;
returns structured status.

Read-only tools

Read-only means the tool is designed not to change business state.

It does not mean:

no logs are created;
no provider request occurs;
no cost is incurred;
no private data is accessed;
the tool is safe for every input.

Read-only tools still require access control and privacy evaluation.

Destructive tools

Destructive tools include operations that can:

delete or revoke records;
transfer or refund money;
change production systems;
disclose restricted information;
publish external content;
change roles or governance status.

They require exact approval or a narrow standing policy, idempotency, audit evidence, and rollback or remedy information.

Resources

MCP resources expose contextual data without granting arbitrary query access.

Examples:

public Foundation documents;
versioned schemas;
product manifests;
selected Passport presentations;
evidence package summaries;
task artifacts;
governance decisions;
conformance reports.

Resource URIs must be stable, authorized, and classification-aware.

Resource templates

Template resources may accept identifiers but must not enable enumeration of private records.

Example:

anuka://products/{product_id}/public-manifest

Permissioned resources should use unguessable references or authorization checks, not secrecy of the URI alone.

Prompts

Prompts are reusable user-invoked workflows, not hidden system authority.

ANUKA prompts may help users:

analyze an opportunity;
prepare a contribution;
review evidence;
compare governance proposals;
draft a product experiment;
inspect a consent request.

Prompt templates must identify:

owner;
version;
intended inputs;
data access;
tools they may suggest;
limitations;
whether generated output requires review.

Elicitation

Elicitation is used when the server requires additional user information or approval.

ANUKA uses elicitation for:

selecting requested Passport claims;
clarifying task scope;
choosing a product or organization;
approving a tool action;
collecting a missing non-secret parameter.

Servers must not use elicitation to request passwords, raw private keys, unrestricted tokens, or secrets that should be handled through secure authorization flows.

Tasks extension

Long-running or interruptible operations use MCP Tasks where supported.

Examples:

evidence-package validation;
repository conformance scan;
large data export;
product quality analysis;
multi-stage contribution review;
controlled agent workflow.

A Task maps to an ANUKA agent task record and includes:

principal;
authorization grant;
task contract;
status;
progress;
approval checkpoints;
durable result reference;
cancellation;
expiry;
audit trail.

Protocol task state must not diverge silently from the canonical ANUKA task state.

Mid-flight input

When a task needs more information, it pauses rather than guessing material parameters.

Mid-flight input requests include:

why the input is needed;
allowed values;
effect on scope or cost;
data classification;
expiry;
whether the task can continue with a safer default.

Cancellation

Cancellation is a request, not a guarantee that all external side effects can be undone.

The task result must indicate:

cancellation accepted;
work stopped;
external side effect may have occurred;
cleanup required;
refund or remedy status.

Skills over MCP

ANUKA skill packages may be discovered through the Skills over MCP extension.

A skill describes how an agent should combine tools, resources, policies, and verification steps for a defined workflow.

Skills do not grant permissions and cannot override tool policy.

The canonical skill source remains a signed, versioned package in a repository or registry.

MCP Apps

MCP Apps may render interactive interfaces such as:

consent selectors;
evidence tables;
task progress;
proposal comparisons;
product quality dashboards;
approval forms.

App UI is untrusted content until verified and must run within the host’s isolation model.

An App must not receive host secrets or unrestricted browser authority.

Authorization

Remote MCP servers use the protocol’s current authorization profile together with ANUKA capabilities and consent.

Authorization must bind:

client;
principal;
server;
tool or resource;
actions;
product and organization scope;
purpose;
expiry;
audience.

A token for one MCP server must not be accepted by another server merely because both are part of ANUKA.

Enterprise-managed authorization

Organization-managed authorization may reduce repetitive user prompts for approved servers and policies.

It must still preserve:

organization visibility;
user notice where required;
least privilege;
product and data boundaries;
revocation;
audit records;
separation from personal accounts.

Central management is not permission to bypass participant consent for participant-controlled data.

Client trust

Servers should evaluate client identity and metadata but must not trust client-provided annotations as authorization evidence.

Hosts should evaluate server identity, operator, artifact, protocol version, and registry status before exposing tools to models.

Server trust

A trusted registry entry may assert:

control of endpoint;
operator identity;
reviewed tool schemas;
artifact provenance;
security contact;
conformance result;
current status.

It does not guarantee every tool result is true or safe.

Error mapping

MCP protocol errors and ANUKA domain errors remain distinguishable.

Examples:

malformed JSON-RPC request;
unsupported protocol revision;
unknown tool;
invalid input schema;
authentication failure;
consent_required;
approval_required;
capability_denied;
task_conflict;
external_side_effect_unknown.

Domain errors should be returned as structured tool results when the protocol request itself was valid.

Telemetry

Requests should propagate W3C trace context through the MCP-supported metadata convention.

Telemetry records:

server and tool ID;
protocol revision;
task ID;
principal category, not unnecessary personal data;
authorization result;
latency;
error class;
token and cost class where available;
approval wait time;
external dependency status.

Tool inputs and outputs are not logged by default.

Caching

Tool and resource discovery responses may be cached according to declared TTL and version.

Authorization-sensitive content must not be shared across principals or organizations through an unsafe cache key.

Tool results are cacheable only when the tool contract explicitly permits it and privacy scope is included.

Deprecation

MCP server features follow both:

the selected MCP protocol lifecycle; and
ANUKA tool-contract deprecation policy.

A deprecated tool advertises:

replacement;
migration guide;
warning date;
removal date;
affected versions;
security reason if accelerated.

Conformance levels

MCP Transport Conformant

Implements required protocol behavior for the selected revision.

ANUKA Tool Contract Conformant

Implements ANUKA schemas, authorization metadata, errors, and audit requirements.

ANUKA Verified Server

Additionally passes operator verification, endpoint control, security review, and current conformance tests.

Conformance is version-specific and expires or requires revalidation.

Test suite

Tests should cover:

protocol revision negotiation;
stateless request behavior;
discovery caching;
JSON Schema validation;
authentication and audience;
consent denial;
approval flows;
read-only and destructive annotations;
Tasks lifecycle;
cancellation after side effect;
malicious tool descriptions;
prompt injection from resources;
data redaction;
trace propagation;
deprecation behavior.

MVP MCP surface

Initial tools and resources should be narrow:

Foundation documentation search;
schema lookup and validation;
public product discovery;
opportunity search;
contribution draft creation;
evidence presentation request;
consent request inspection;
private evidence summary with explicit authorization;
conformance scan;
agent task status.

Production mutations, payments, role changes, and sanctions remain proposal-only or human-approved.

Acceptance criteria

protocol revision is pinned;
every server has an operator and stable identity;
every tool maps to an ANUKA capability;
schemas are bounded and versioned;
resources respect data classification;
Tasks map to canonical task records;
Skills cannot grant authority;
Apps run under host isolation;
tokens are server- and audience-bound;
telemetry excludes raw sensitive payloads by default;
protocol errors and domain errors are distinct;
conformance tests cover consent, approval, injection, and cancellation;
high-impact mutations cannot run autonomously.

Sources

Verification record

Sources opened and checked: 2 August 2026
MCP protocol page available: 2026-07-28
MCP implementation status: Draft profile
Required production conformance: Yes