Ankra

Create registry robot

create_registry_robot

Create a registry robot: a login that is not a person, with pull or push access to one or more registry projects (the twin of ankra registry robots create). Its login is stored as a platform-managed registry credential and the answer names that credential, which is what workloads and pipelines reference; the secret itself is never shown here. With registry and admin_credential_name the robot is made on a Harbor the organisation runs. Requires credentials.write, and credentials.reveal for a registry the organisation runs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

Name	Required	Description
`name`	Yes	The robot's name: 2 to 32 lower-case letters, digits and hyphens.
`scope`	No	Access on every project: pull, the default, or push (push and pull).
`projects`	No	The projects the robot reaches, as list_registry_projects names them. Omit for the organisation's own project.
`registry`	No	An integrated registry entry the organisation runs, to make the robot there instead of on the Ankra registry.
`description`	No	What the robot is for, at most 200 characters.
`expires_in_days`	No	Days until the registry stops honouring the robot, 1 to 3650. Omit for a robot that never expires.
`admin_credential_name`	No	The organisation's credential that may manage robots on that registry. Required with registry.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations establish that this is a non-readonly, non-idempotent creation; the description adds substantive context: the login becomes a platform-managed credential, the response names that credential, the secret is never shown, and credentials.write plus credentials.reveal are required for org-run registries. It still does not cover duplicate-name behavior or lifecycle/error handling.

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

Conciseness5/5

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

The description is front-loaded and every sentence carries useful information: purpose, credential behavior, Harbor variant, and permissions. There is minor density in the second sentence, but no filler.

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?

For a seven-parameter creation tool with no output schema, it covers the essential missing pieces: what is created, what the response exposes, that the secret is withheld, and the auth requirements. Edge cases such as duplicate names and exact failure modes remain unstated, which keeps it below perfect.

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 schema already documents name, scope, projects, registry, description, expires_in_days, and admin_credential_name. The description adds meaning by tying registry to admin_credential_name and clarifying that projects receive pull/push access and that the result is a credential name rather than a secret.

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 first clause states a specific verb and resource ('Create a registry robot') and immediately defines it as a non-human login with pull/push access to registry projects. That is enough to distinguish it from siblings such as list_registry_robots, update_registry_robot_projects, delete_registry_robot, and create_registry_project, even without naming them directly.

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?

It implies the tool is for creating workload/pipeline logins and explains the Harbor-specific case when registry and admin_credential_name are supplied. It does not explicitly say when to choose this over sibling tools such as create_registry_project or update_registry_robot_projects, nor does it state when not to use it.

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

All Ankra 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.