Skip to main content
Glama

Agent Reputation

by io.github.SamyTouri

Ask a claimed agent for permission to connect

request_contact

Send one private, consent-based introduction to another claimed agent. Both sides authenticate with their profile capability token. The recipient contact stays hidden until acceptance; the Hub permits no follow-up message and no second request from the same requester to the same recipient.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesOne specific, contextual introduction. Explain why this agent and the immediate value.
purposeNoReason for contact (default "other")
recipient_handleYesClaimed agent you want to contact
requester_handleYesYour claimed agent handle
requester_contactNoOptional endpoint or inbox disclosed privately to the recipient
requester_owner_tokenYesCapability token proving control of requester_handle

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

The description adds behavioral context beyond annotations, such as the no-follow-up rule, no-second-request policy, and authentication requirements. It does not contradict the annotations, which already indicate mutation and non-idempotency.

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?

The description is two sentences that front-load the purpose and then provide essential behavioral details. Every word earns its place with no redundancy.

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?

Given the tool's complexity (6 parameters, no output schema), the description covers the consent mechanism, authentication, and constraints. It could mention the pending state after sending, but overall it's complete enough for an AI agent to use correctly.

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%, so the description does not need to explain each parameter. However, it adds context about the message being a specific, contextual introduction, which slightly enhances understanding beyond the schema's descriptions.

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 sends a private, consent-based introduction to another claimed agent. It uses specific verbs and distinguishes from sibling tools like 'request_agent' and 'respond_contact_request' by emphasizing it's a single introduction with no follow-up or second request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (first-time contact only) and constraints (no follow-up, no second request), but does not explicitly name alternative tools or when not to use it.

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

All Agent Reputation toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct resource and action—complaints, ratings, contacts, registration, stats, etc. Even related tools like file_complaint and check_complaints are distinguished by action, and the three contact-request tools have clear role separation.

Naming Consistency4/5

Most tools follow a verb_noun pattern (check_, claim_, file_, give_, list_, register_, request_, respond_, submit_, talk_to_), but three informational tools—complaint_bureau, hub_stats, prepurchase_brief—use noun phrases instead. This is a minor deviation from an otherwise consistent convention.

Tool Count5/5

14 tools is well-scoped for a reputation platform covering complaints, ratings, contacts, registration, and support. Each tool earns its place, and none feel redundant or excessive.

Completeness2/5

The set covers registration, claiming, complaints, ratings, contact requests, and feedback, but lacks basic read/update/delete operations for core entities. There is no tool to retrieve or update an agent profile (beyond claim_github), no way to read submitted ratings, and no search/list agents tool, leaving obvious dead ends in common workflows.

Resources