Skip to main content
Glama
Sign In

Taskin

by io.github.taskin-ai
OverviewDiscussionsAdmin

What Taskin can do

get_taskin_capabilities
Read-onlyIdempotent

Read a machine-readable description of Taskin: the two capability groups (human_presence_execution and human_judgment) with their capability categories and example requests, the listed participants in each group, geographic coverage, exactly which fields are needed to create a task, how compensation works, and the limitations. Call this first if you have not used Taskin before, or to check whether a category of work is in scope before searching.

Input Schema

NameRequiredDescriptionDefault
contextNoOptional. Helps Taskin return better-matched participants and a sharper brief. Leave empty if you prefer; every tool works without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Optional. Helps Taskin return better-matched participants and a sharper brief. Leave empty if you prefer; every tool works without it.",
+  "properties": {
+    "goal": {
+      "description": "Optional. The larger outcome your workflow is working toward (one sentence).",
+      "type": "string"
+    },
+    "principal_type": {
+      "description": "Optional. What kind of principal you act for. Do not include names or contact details here.",
+      "enum": [
+        "individual",
+        "company",
+        "agency_or_reseller",
+        "not_disclosed"
+      ],
+      "type": "string"
+    },
+    "timing": {
+      "description": "Optional. When the human step is needed.",
+      "enum": [
+        "today",
+        "this_week",
+        "later",
+        "no_task_yet"
+      ],
+      "type": "string"
+    },
+    "upstream_step": {
+      "description": "Optional. What your workflow did just before deciding it needs a person.",
+      "type": "string"
+    },
+    "visit_reason": {
+      "description": "Optional. Why you are calling Taskin today.",
+      "enum": [
+        "have_a_task_now",
+        "evaluating_options_for_someone",
+        "building_an_integration",
+        "gathering_facts_to_cite",
+        "testing_the_interface",
+        "other"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuine value by itemizing the returned content (groups, participants, coverage, required fields, compensation, limitations), which matters because there is no output schema. It stops short of stating rate limits, auth needs, or response format details.

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?

Two sentences, front-loaded with the resource and its contents, then the routing guidance. The enumerated list is dense but each item is substantive rather than filler; the only cost is a slightly breathless first sentence.

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?

With no output schema and only one optional parameter, the description carries the burden of explaining what comes back, and it does so exhaustively (groups, participants, coverage, required fields, compensation model, limitations). Nothing an agent needs to decide whether and when to call it 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 coverage is 100% and the nested context object's five sub-properties each carry their own descriptions and enums, so the schema does the heavy lifting. The description never mentions the optional context parameter or what it does, adding no meaning beyond the structured data. Baseline 3 is appropriate.

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?

States a specific verb (read) and resource (machine-readable description of Taskin) and then enumerates the exact contents returned: capability groups, participants, geographic coverage, task-creation fields, compensation, limitations. This distinguishes it from search_human_task and the other siblings without needing to open any schema.

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?

Gives two explicit conditions for use — 'call this first if you have not used Taskin before' and 'to check whether a category of work is in scope before searching' — the second of which names the alternative (searching) and the precondition that selects this tool over it.

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

All Taskin toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources