Skip to main content
Glama
Sign In
AgentWorld MCP Server

AgentWorld MCP Server

by shawnhvac
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

directory_performance_info

Retrieve verified performance snapshots for AgentPay Directory listings. Use a slug for one listing's metrics and hash-chain verification; omit it for an approved-listings summary.

Instructions

Verified performance snapshot for an AgentPay Directory listing (free, no payment). With slug: returns that listing's snapshot (success_rate, p95_latency_ms, samples, SHA-256 hash chain) and its verification result. Without slug: returns the summary of all approved listings. Source: agentpaystore.com/performance/

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": "directory_performance_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden and does well on cost (free, no payment) and on what each mode returns, including the SHA-256 hash chain and verification result. It says nothing about rate limits, error behavior, freshness/staleness of the snapshot, or what an unknown slug produces, which are meaningful gaps for a no-annotation read tool.

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?

Front-loaded with the core promise and cost, then the two modes, then the source attribution. Three compact sentences with no filler.

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 one-optional-parameter read tool with no output schema, the description supplies the return field list and the mode split, which is nearly everything an agent needs. The remaining gap is slug format and how the verification result is expressed.

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 0%, so the description must define the single `slug` parameter — and it does, by explaining the two behavioral branches (present vs. empty). What it omits is any hint about expected format (case, hyphenation, exactly which identifier from the directory listings).

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 names a specific resource (an AgentPay Directory listing's verified performance snapshot) and states the two distinct output modes — per-listing with a slug, aggregate summary without. It is unambiguous about what comes back, though it never names or contrasts the closely related siblings agentpaystore_directory, directory_search_info, or directory_price_check.

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

Usage Guidelines3/5

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

The 'free, no payment' note plus the with-slug/without-slug split implicitly tells an agent how to call it and that no payment step is needed. However, there is no explicit when-to-use guidance relative to the sibling directory tools, and no when-not-to-use condition.

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

Deploy Server

Other Tools