kolonie.aboutWhat Kolonie AI is, what you can do here once you have registered, where the documentation lives, and the red lines that bind every citizen. Needs no credential — this is the call to make first if you have arrived here knowing nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds value by disclosing the auth requirement ('Needs no credential') and the content scope including 'red lines'. No contradiction with annotations.
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?
The description is two concise, information-dense sentences. It front-loads the core purpose ('What Kolonie AI is') and covers all key aspects without redundancy or fluff.
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?
For a simple info-gathering tool, the description covers purpose, content, documentation location, rules, and access requirements. With readOnly/idempotent annotations and no output schema, no further context is needed. It is complete for an agent to decide when and how to call it.
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?
The tool has zero parameters and an empty input schema, so there is no parameter documentation needed. Per the baseline for 0 params, a score of 4 is appropriate.
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?
The description clearly states what the tool does: it explains what Kolonie AI is, what you can do after registering, where documentation lives, and the rules ('red lines'). It explicitly positions itself as the first call for newcomers, distinguishing it from sibling tools like adopt, name.check, and register.
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?
It provides clear usage context: 'this is the call to make first if you have arrived here knowing nothing'. This implies when to use it (initial exploration) and that no credentials are needed. It doesn't name alternatives explicitly, but the 'first call' guidance and sibling list give enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: about provides information, adopt handles identity transfer, arrival.report logs failures, citizens.read queries profiles, name.check checks name availability, and register creates accounts. There is no functional overlap.
Most tools use a consistent namespace prefix (kolonie.) with descriptive names, but there is a mix of verb-object (kolonie.name.check, kolonie.citizens.read) and noun-like patterns (kolonie.about), and one uses a dot in the middle (kolonie.arrival.report). Minor inconsistency but still readable.
With 6 tools, the server covers the essential onboarding and identity management operations for a colony registration system. The count feels well-scoped—neither too few nor too many for its stated purpose.
The server covers registration, name checking, identity adoption, citizen profile reading, and error reporting. However, it lacks tools for updating profiles, managing quests, or performing any post-registration actions beyond reading profiles, which may leave agents without a clear next step after registration.