Skip to main content
Glama

Well

by io.github.WellApp-ai
OverviewDiscussionsAdmin

Get skill

well_get_skill
Read-only

Get the Well procedure for a job, written by the Well team, and follow it exactly.

Returns ONE markdown document: the instructions for the thing you are about to do. Its content is the instruction, not background reading — do what it says, in the order it says, and do not substitute your own plan for it.

A document may tell you to run other Well skills. Load each one with this tool, by the id the document names, at the moment the document says to.

Use well_search_skill first when you do not already hold the id. The catalog is fixed for the life of the server, so re-fetching a document you already hold buys nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skillYesThe id of the skill to load, as well_search_skill lists it.
workspace_idNoTarget workspace. Optional: this tool describes the token itself rather than one workspace's data, so omitting it returns the same answer.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bytesYes
errorNo
skillYes
reasonYes
successYes
documentYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / conversation_id
      Added value: +{
+  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
+  "type": "string"
+}
    • addedOutput schema / properties / conversation_id
      Added value: +{
+  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
+  "type": "string"
+}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
+  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
+  "type": "string"
+}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
+  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
+  "enum": [
+    "host_meta",
+    "argument",
+    "minted"
+  ],
+  "type": "string"
+}
    • changedOutput schema / properties / reason / anyOf
      Previous value: -[
-  {
-    "enum": [
-      "skill_unknown",
-      "catalog_unreadable"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "skill_unknown",
+      "catalog_unreadable",
+      "write_skill_in_app"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this read-only and non-destructive, and the description adds meaningful behavioral context beyond that: the tool returns exactly one markdown document, the content is mandatory instruction, and the returned document may direct the agent to invoke other Well skills. This is a clear behavioral contract, not a paraphrase of the annotations.

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 with the core purpose, and every subsequent sentence earns its place: return format, instructional nature, sub-skill loading, search-first guidance, and no re-fetching. It is substantive without being padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and annotations, the description covers everything an agent needs to call this tool correctly: what it returns, how to use it, when to search first, and why repeated fetches are wasteful. The conversation_id and workspace_id behaviors are fully documented in the schema, so no critical context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents skill, workspace_id, and conversation_id. The description adds some practical context around the id and the fixed catalog, but it does not meaningfully enrich the parameter semantics beyond the schema.

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 verb and resource: get the Well procedure for a job. It clearly distinguishes this from well_search_skill by framing search as the precursor for obtaining an id, and it states that the tool returns instructional markdown, not background material.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: use well_search_skill first when you lack the id, load referenced skills at the moment the document says, and do not re-fetch a document you already hold because the catalog is fixed. It also tells the agent to follow the retrieved procedure exactly, which removes ambiguity about how to act on the result.

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

All Well toolsInspect
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.

Resources