hunchful

As whom and to whom: where you can publish

list_identities

Read-onlyIdempotent

AS WHOM and TO WHOM the person can publish — call it before create_post, create_event or upload_media when they say "post this as …" or "for the members". Each identity is one of what they run (a förening's, a company's or community's home, a creator or topic channel, a class) with its key (pass it as as), their role, and its place: the channel and the audiences it offers THEM (everyone · followers · members = the home's Nyheter · team · subscribers), whether under-18s can see it (then everything you write is a draft they publish) and whether your app may publish there directly. Their own friends feed and CV are theirs alone (not here). With the Messages scope: also the group chats and #kanaler they write in as themselves (send_to_conversation). Read only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	Yes
`chats`	Yes
`identities`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedOutput schema / properties / identities / items / properties / place / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "audiences": {
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "channelId": {
-        "type": "string"
-      },
-      "publishesDirectly": {
-        "type": "boolean"
-      },
-      "under18CanSee": {
-        "type": "boolean"
-      },
-      "usual": {
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "channelId",
-      "audiences",
-      "usual",
-      "under18CanSee",
-      "publishesDirectly"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "audiences": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "brief": {
+        "description": "The owner's brief for you: what this channel is, its voice, its themes, what it never says. Follow it when you write as this identity.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "channelId": {
+        "type": "string"
+      },
+      "official": {
+        "type": "boolean"
+      },
+      "publishesDirectly": {
+        "type": "boolean"
+      },
+      "under18CanSee": {
+        "type": "boolean"
+      },
+      "usual": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "channelId",
+      "audiences",
+      "usual",
+      "under18CanSee",
+      "publishesDirectly",
+      "brief",
+      "official"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

AddedOct 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds real behavioral context beyond them: the under-18 rule that everything written becomes a draft the person must publish, and the per-identity flag for whether the app may publish directly. It also discloses a scope-dependent capability (group chats/#kanaler via send_to_conversation). It does not discuss staleness, caching or rate limits, so it is not a 5.

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

Conciseness3/5

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

Purpose and the critical 'call it before create_post' instruction are front-loaded, but the body is a single sprawling sentence with deeply nested parentheticals, slashes and em-dashes that make it hard to parse. Information-dense, yet it would be stronger split into a few short sentences.

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 zero-parameter, read-only listing tool with an output schema (so return format needn't be explained) and annotations covering the safety profile, the description supplies the missing why-and-when context, draft-publication rules and scope variants. Nothing essential for correct invocation is absent, though the coverage could be organized more cleanly.

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?

There are zero input parameters, so the baseline is 4. The description does add meaning about the returned identity record (key passed later as `as`, role, channel, offered audiences, publishability), which helps the agent map output fields to its next call, but that is output rather than parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys a specific resource: the identities ('as whom') a person can publish as and the audiences ('to whom') each offers, plus their key, role and publish permissions. It clearly distinguishes this from the write-side siblings (create_post, create_event, upload_media). It is clear but stated in metaphor-heavy prose rather than a plain verb+resource, so it stops short of a 5.

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?

Explicit when-to-use with named triggers ('when they say "post this as …" or "for the members"') and explicit precondition ('call it before create_post, create_event or upload_media'). It also names the scope-dependent extension (Messages scope → send_to_conversation) and excludes non-members ('Their own friends feed and CV are theirs alone (not here)').

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

All hunchful tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold 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.