Skip to main content
Glama

Get a service

get_service
Read-only

Fetch one catalog service by slug with metadata and a requestShape block. Read the endpoint's payServiceArgs before pay_service, replacing every pathParams placeholder. A checked invoke contract may include invokePath, requestExample, merchant-authored responseSchema/responseExample, and exampleEvidence: paid-run records a paid response, challenge proves only the request shape, and docs is unverified provider documentation. Only paid-run and challenge examples are pre-filled into payServiceArgs; adopt a docs example deliberately. Each endpoint also carries requestExampleQuality, grading how well it publishes the way to call it (not a callability verdict) — proven (a usable example earned against the real endpoint, including a concrete invokePath that fills a templated path), docs (a usable example from documentation, unverified), no-input (takes no request input, callable as-is), or none (no stored example — form the request from requestSchema if one is published). Merchant response shapes are sanitised, and harvested examples are published only when they validate against their schema. An endpointCheck records a dated unpaid failure. An endpoint with auth: "siwx" is not paid: it is a follow-up (a job or result poll) that only the wallet which paid an earlier call to the same service can read, so call it with pay_service after that call, filling its pathParams with the id the paid response returned; the Router signs the wallet challenge and charges nothing. A requestSchema is the merchant-declared JSON Schema of its request and is sanitised, not verified. A quote excludes the Router fee, which the budget must also cover. An unknown slug returns an error. Discovery only; no payment. Call quote_service for the live fee-inclusive total before paying.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_service"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe service slug (from search_services).

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.5/5.0
Behavior5/5

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

Beyond `readOnlyHint`, the description discloses substantial behavior: what blocks may appear in the response, how example evidence is classified, that merchant schemas and responses are sanitised, that harvested examples are validated, that unknown slugs return an error, and that no payment occurs. This gives an agent unusually rich context for interpreting the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence, but the rest is a dense, single-paragraph block covering many nested concepts such as `exampleEvidence`, `requestExampleQuality`, sanitisation, `auth: "siwx"`, and Router fees. Much of that context is useful, but the volume and packing make it harder to scan than necessary for a one-parameter read tool.

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?

There is no output schema, so the description must explain the response structure, and it does so thoroughly: `requestShape`, invoke contract fields, example evidence, quality grades, `endpointCheck`, and sanitisation. It also covers the key failure mode (unknown slug) and payment boundaries, leaving little an agent needs to infer.

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?

The schema already documents the single `slug` parameter at 100% coverage, including that it comes from `search_services`. The description adds the behavioral note that an unknown slug returns an error, but does not add further meaning about the slug format or sourcing beyond what the schema provides.

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 opening sentence names a specific verb and resource: fetching one catalog service by slug, including the returned metadata and `requestShape` block. It is clearly distinguishable from siblings like `search_services` and `pay_service`, so an agent can identify the tool without opening its schema.

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 routes the agent: read `payServiceArgs` before calling `pay_service`, use `quote_service` for the fee-inclusive total before paying, and it states that this tool is discovery-only with no payment. It also explains the special `auth: "siwx"` follow-up case and when to call it with `pay_service`.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources