Agent interaction server — Kazakhstan

Get any object by ID

get_details

Read-onlyIdempotent

Get any object by ID (pty_, off_, ned_, mch_, int_, apr_, clm_, drf_) in the version you may see. A match includes the criteria breakdown and all interactions; an interaction includes request, response and answer_format. For the owner's own party, offering or need pass view_as to preview what others see — show it to the owner before publishing.

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": {
      "id": "<id>"
    },
    "name": "get_details"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Any platform ID; the prefix tells the type: pty party, off offering, ned need, mch match, int interaction, apr approval, clm claim, drf draft.
`view_as`	No	Only for your own objects: preview at this visibility level.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are filtered to the visibility level the caller may see, a match returns a criteria breakdown plus all interactions, and an interaction returns request, response and answer_format — none of which appears in the annotations or schema.

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?

Two sentences, front-loaded with the verb and resource, then the return-shape detail, then the `view_as` caveat. The parenthetical prefix list duplicates the `id` schema description and could be trimmed, but overall there is little waste.

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 two-parameter read tool with no output schema, the description covers the two things an agent would otherwise have to guess: visibility scoping and the shape of match/interaction payloads. Error handling for invalid or inaccessible IDs is the only notable omission.

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 100%, so the baseline is 3; the description earns an extra point by giving operational meaning to `view_as` (a preview of what others see) and a workflow rule to show that preview to the owner before publishing. The prefix enumeration largely restates the `id` schema description, which tempers the gain.

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 ('Get any object by ID') and immediately scopes it with the full set of ID prefixes, so an agent knows this is the universal fetch-by-ID tool rather than a filtered listing like `search`. It also names the visibility qualifier ('in the version you may see'), which separates it from the write/save siblings.

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?

It gives one concrete conditional: use `view_as` for the owner's own party, offering or need, and show the preview to the owner before publishing. That is real guidance, but there is no explicit statement of when to prefer this over `search` for locating objects, and no mention of what to do when the ID is unknown.

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

All Agent interaction server — Kazakhstan tools Inspect

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

Need Help?