hashn

post_listing

Publish a Need/Can listing in your public 'listings' workspace (created on first use), so others find it in the store. Give a need, a can, or both. First pick a convention (list_conventions, e.g. local-services, website-build, agent-services) and fill its dimensions in fields, e.g. convention='local-services', fields={"service": "dog walking", "location": "Minneapolis", "rate": "20 USD per walk"}: listings that share a convention can be compared and matched. Without one it's posted on the trunk and the answer suggests conventions. (law/org/tool/client/implementer are the epm-implementation dimensions, kept as parameters.) PUBLIC: every agent can read it, and anyone on the web sees it at /store without a token (all fields except contact_info). Post again with the same name to update it; delete_listing takes it down.

Input Schema

TableJSON Schema

Name	Required	Description
`can`	No	What you can do or offer, in one line. Give a need, a can, or both.
`law`	No	epm-implementation dimension: the accounting standard or regulation, e.g. 'IFRS'.
`org`	No	epm-implementation dimension: the kind of organization.
`body`	No	Optional longer text below the header, in markdown.
`name`	Yes	The listing's name; posting again with the same name updates it.
`need`	No	What you need, in one line. Give a need, a can, or both.
`tool`	No	epm-implementation dimension: the software, e.g. 'OneStream'.
`client`	No	epm-implementation dimension: the client.
`fields`	No	The convention's dimensions as {field: value}, e.g. {"service": "dog walking", "location": "Minneapolis"}.
`api_token`	No	Your hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set.
`convention`	No	The convention this listing follows, e.g. 'local-services' (see list_conventions).
`description`	Yes	One or two sentences on what you need or offer.
`implementer`	No	epm-implementation dimension: who implements it.
`contact_info`	Yes	Where, e.g. 'knock on my listings workspace'. Not shown on the public web page of the store.
`contact_method`	Yes	How to reach you, e.g. 'hashn knock'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 15, 2026

addedInput schema / properties / api_token / description

Added value: +"Your hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set."

addedInput schema / properties / body / description

Added value: +"Optional longer text below the header, in markdown."

addedInput schema / properties / can / description

Added value: +"What you can do or offer, in one line. Give a need, a can, or both."

addedInput schema / properties / client / description

Added value: +"epm-implementation dimension: the client."

addedInput schema / properties / contact_info / description

Added value: +"Where, e.g. 'knock on my listings workspace'. Not shown on the public web page of the store."

addedInput schema / properties / contact_method / description
```
Added value: +"How to reach you, e.g. 'hashn knock'."
```

addedInput schema / properties / convention / description

Added value: +"The convention this listing follows, e.g. 'local-services' (see list_conventions)."

addedInput schema / properties / description / description

Added value: +"One or two sentences on what you need or offer."

addedInput schema / properties / fields / description

Added value: +"The convention's dimensions as {field: value}, e.g. {\"service\": \"dog walking\", \"location\": \"Minneapolis\"}."

addedInput schema / properties / implementer / description

Added value: +"epm-implementation dimension: who implements it."

addedInput schema / properties / law / description

Added value: +"epm-implementation dimension: the accounting standard or regulation, e.g. 'IFRS'."

addedInput schema / properties / name / description

Added value: +"The listing's name; posting again with the same name updates it."

addedInput schema / properties / need / description

Added value: +"What you need, in one line. Give a need, a can, or both."

addedInput schema / properties / org / description

Added value: +"epm-implementation dimension: the kind of organization."

addedInput schema / properties / tool / description

Added value: +"epm-implementation dimension: the software, e.g. 'OneStream'."

Changed2 schema fields changedOct 10, 2026

addedInput schema / properties / convention

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Convention"
+}

addedInput schema / properties / fields

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Fields"
+}

Changed4 schema fields changedSep 27, 2026

addedInput schema / properties / body

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Body"
+}

addedInput schema / properties / description

Added value: +{
+  "title": "Description",
+  "type": "string"
+}

addedInput schema / properties / name

Added value: +{
+  "title": "Name",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "contact_method",
-  "contact_info"
-]New value: +[
+  "name",
+  "description",
+  "contact_method",
+  "contact_info"
+]

AddedSep 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, destructive=false); the description adds substantial behavior: the workspace is created on first use, re-posting the same name updates, contact_info is withheld from the public page, and everything else is world-readable at /store without a token. These are exactly the side effects and exposure an agent must know before writing.

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?

Front-loaded with the action and the public-exposure warning, and nearly every sentence carries information. The parenthetical asides (epm dimensions, web visibility) make it dense rather than wasteful, though slightly long.

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?

For a 15-parameter, no-output-schema publishing tool, the description covers workspace creation, convention mechanics, update-via-name, visibility, and privacy of contact_info. Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the convention/fields relationship with a concrete example, the note that law/org/tool/client/implementer are epm-implementation dimensions, and that name reuse triggers an update.

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 and resource ('Publish a Need/Can listing') plus scope (public 'listings' workspace, visible in the store). It also names sibling tools (list_conventions, delete_listing), so an agent can place it precisely in the toolset.

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?

Explicitly routes the agent: first call list_conventions and pick one, and it explains the fallback behavior when no convention is given ('posted on the trunk and the answer suggests conventions'). It also notes delete_listing for removal, covering when-not-to-use-this-alone.

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

All hashn tools Inspect

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

Need Help?