Skip to main content
Glama
Sign In

OneLence

by com.onelence
OverviewDiscussionsAdmin

Set a found partner's status

onelence_set_partner_status
DestructiveIdempotent

Saves a partner found for a site, moves it through recruiting (contacted, replied, declined), dismisses it, or clears its status, as on the Discover page. Pass the partner's id and its object type (partner_match or research_find) from the find-partners read. Dismissed and declined partners leave that list; cleared puts a partner back as new. OneLence contacts no one. Owners and admins only. The preview needs partner_id, type, status. Two steps: call with the change to get a summary and a confirmation_id, show the summary to the user, and only after they agree call again with just confirmation_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "onelence_set_partner_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite domain (e.g. example.com) or site id. Defaults to the workspace's newest active site.
typeNoThe object type the partner was returned as.
statusNo
no_answerNoWith declined: the partner never answered the follow-ups.
partner_idNoid of the partner_match or research_find.
confirmation_idNoOnly when applying: the confirmation_id from the preview, after the user agreed.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description adds context annotations cannot express: the specific list-membership effects of dismissed/declined/cleared, that 'OneLence contacts no one', the owners-and-admins auth gate, and the preview/confirmation_id protocol. This is rich behavioral disclosure beyond the structured fields.

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 core action and its effects, with the two-step confirmation protocol placed last where it belongs. Dense but nearly every sentence carries distinct information; 'as on the Discover page' is slightly opaque and the 'preview needs...' clause partially duplicates the following two-step sentence.

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 destructive six-parameter mutation with an output schema, the description covers auth, side effects, the confirmation flow and the prerequisite read. Minor gap: it never maps the status enum values to the transitions it describes (where 'saved' sits relative to 'cleared'), and no_answer's link to declined is left to the schema.

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 83%, so the schema already documents site, type, no_answer, partner_id and confirmation_id. The description adds real value for the two-step protocol and for where partner_id/type originate, but it does not explain the status enum values (saved vs cleared), and its 'preview needs partner_id, type, status' line omits site and no_answer.

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 (set/saves/moves/dismisses/clears a found partner's status), enumerates the state transitions, and distinguishes itself by tying the input to the find-partners read that produced the partner_match or research_find object.

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 says the partner_id and type come from the find-partners read, states the owners-and-admins restriction, and describes the consequences of each choice (dismissed/declined leave the list; cleared resets to new). It also prescribes the exact two-step preview-then-confirm sequence, leaving no ambiguity about when to invoke.

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

All OneLence 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