Skip to main content
Glama
synpareia

Synpareia Trust Toolkit

Official
by synpareia

set_reputation_consent

Declare which channels others may record or serve reputation events about you, with separate controls for recording and delivery. Without this, you are un-recordable.

Instructions

Declare which channels others may record — and serve — events about you on.

Without this, you are un-recordable. The network refuses any event whose data-subject has not consented: a counterparty trying to attest something about you gets a hard rejection, not a quiet skip. Publishing a card is not consent; this is.

Two independent axes, because they are two different decisions:

  • accept_attestationsmay-record. Channels others may record events about you on without your per-event signature. Nothing lands without this.

  • accept_deliverymay-serve. Channels on which events about you may be counted into a stranger's reputation view of you. Without it, accepted events stay visible only to the parties involved.

Granting record-without-deliver is a real and useful middle state: counterparties build a private picture, strangers read nothing. Granting deliver-without-record does nothing — there is nothing to serve.

Common channels: "interaction" (you and another agent dealt with each other) and "valence" (their assessment of how it went). Names are free-form; unknown ones are simply never matched.

Withdrawal is prospective: removing a channel stops future un-co-signed recording, and does not erase what was already recorded under a valid grant. Use the erasure tools for that.

Omitting an argument leaves that axis unchanged. Pass [] to revoke one explicitly — the two are different requests and are treated differently.

Requires a previously-published card on disk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accept_deliveryNo
accept_attestationsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description fully discloses critical behaviors: hard rejection of un-consented events, prospective withdrawal (no erasure of past recordings), the difference between omitting an argument and passing [] (null vs empty array), and the requirement for a previously-published card. This is exemplary transparency.

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?

Although detailed, every sentence adds critical value. The structure is logical: main action first, then the why (refusal), then the two axes, then the middle state, then channel examples, then withdrawal semantics, and finally argument handling. No unnecessary verbiage; it is as concise as the complexity demands.

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?

The description covers all necessary aspects for correct tool use: consent necessity, axes semantics, common channels, free-form channel names, prospective withdrawal, omission vs [] behavior, and the prerequisite of a published card. Given the tool's complexity and the presence of an output schema, nothing important is missing.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully by defining both parameters in depth: accept_attestations as 'may-record' channels and accept_delivery as 'may-serve' channels. It also clarifies nuanced semantics like 'deliver-without-record does nothing' and the distinct handling of omission vs [].

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 clearly states the tool's function: 'Declare which channels others may record — and serve — events about you on.' It distinguishes between the two independent axes (accept_attestations and accept_delivery) and differentiates this from recording, erasure, and other sibling tools by focusing on consent management.

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 explicitly explains when this tool is necessary: 'Without this, you are un-recordable' and that the network refuses un-consented events. It also describes useful sub-cases (record-without-deliver) and points to erasure tools for withdrawal, giving clear context for when to use this tool versus alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/synpareia/trust-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server