Skip to main content
Glama

Oi

by io.github.carhaix

Create Skill

oi.skills.create

Create an Oi Skill in the current organization. By default this creates a private draft; publish: true releases the initial version and publishes it publicly.

Plan and Billing

Current organization plan: Business. Current limits: 10,000 seats; 10,000 private Guardrails; 10,000 private Skills; 10,000 private Contexts; 10,000 private Workflows; 10,000 Connections; 10,000 API keys; 1,000,000 Agent messages per day; 1,000,000 Agent messages per month. Billing and upgrades: https://app.oioioi.ai/dashboard/organization/billing. When a user asks for work that exceeds the current plan or an unavailable paid capability, do the portion available on the current plan, clearly say what is blocked by the plan, and include the billing link for upgrading. Do not invent exceptions, temporary limit increases, prices, or hidden capabilities.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSkill name.
slugNoOptional organization-unique slug.
tagsNoOptional tags.
contentNoMarkdown Skill content.
publishNoWhether to release and publish the Skill publicly after creation.
releaseNoWhether to release the initial draft as version 1 after creation.
categoriesNoOptional category labels.
contextRefsNoOptional Context ids or slugs this Skill should use.
descriptionNoOptional description.
exampleUseCasesNoOptional example uses.
shortDescriptionNoOptional short summary.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
skillYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the skill starts as a private draft, that `publish: true` also releases the initial version, and that plan limits constrain what the agent can do. It adds concrete billing and fallback instructions that are not present in the schema or annotations, and it does not contradict any annotation.

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

Conciseness4/5

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

The core behavior is front-loaded in the first sentence, and the plan/billing content is separated under its own heading. However, the limits list is verbose and includes many values not directly relevant to skill creation, so the description is not maximally tight.

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 a rich input schema, an output schema, and annotations, the description covers the essential behavioral nuances and the plan context that can block creation. It could be more complete by explicitly routing to sibling tools for update/publish operations, but an agent has enough information to call the tool correctly.

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?

The input schema already covers all 11 parameters, so the baseline is 3. The description adds meaning by explaining the interaction between `publish`, `release`, and the private-draft default, which is not fully obvious from the individual parameter descriptions. The remaining parameters are well documented by the 100% schema coverage.

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 description opens with a specific action: 'Create an Oi Skill in the current organization' and immediately clarifies the default lifecycle state, a private draft. This makes the resource and verb unmistakable and distinguishes it from siblings like oi.skills.get, oi.skills.list, oi.skills.update, and oi.skills.publish.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: creating a new skill, with the option to publish immediately via `publish: true`. It implies that updating or publishing existing skills belongs to sibling tools, though it does not explicitly name alternatives such as oi.skills.update or oi.skills.publish.

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

All Oi toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Resource prefixes (contexts, skills, guardrails, workflows, connections) make most tools clearly distinct, and parallel lifecycle verbs are scoped by resource name. The main ambiguity is within the guardrails publish/release/unpublish lifecycle and between brain.save-feedback, contexts.save-draft-feedback, and the two report tools, though detailed descriptions mostly resolve it.

Naming Consistency4/5

Tools overwhelmingly follow an oi.<resource>.<verb> snake_case pattern, with create/get/list/update/use repeated consistently across resource types. Deviations include resource-less oi.recommend, noun-style oi.auth.whoami, and inconsistent release handling (separate guardrails.release vs action=release on contexts/skills update).

Tool Count2/5

38 tools is too many for a single server, mainly because the same lifecycle pattern is repeated across Contexts, Skills, Guardrails, and Workflows. Each tool may be individually justifiable, but the set feels bloated and could benefit from consolidation or splitting into per-resource servers.

Completeness3/5

CRUD coverage is uneven: Guardrails have create/update/delete/list/get plus publish/unpublish/release, while Contexts, Skills, and Workflows lack any delete or archive tool, and Brain has only save-feedback with no read/update/delete path. Connections and auth are read/use-only, which may be intentional but leaves management actions absent.

Resources