Revly

Hent forespørsler til klienten

hent_forespoersler

Read-onlyIdempotent

Henter opptil 80 forespørsler til klienten på én eksplisitt oppdrags-ID: område, kategori, tilstand, sendt dato, svarfrist, svardato, antall purringer og om revisor har vurdert svaret. Tittel, beskrivelse, svartekst og mottaker er utelatt. Interne forespørsler er ikke med. «Ikke vurdert» betyr at ingen vurdering er registrert, ikke at svaret er tilstrekkelig.

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": {
      "oppdrag_id": "<oppdrag_id>"
    },
    "name": "hent_forespoersler"
  }
}

Input Schema

Name	Required	Description	Default
`oppdrag_id`	Yes	Eksplisitt oppdrags-ID fra Revly. Oppslag uten ID er ikke tillatt.

Output Schema

Name	Required	Description
`aar`	No	Engagement year.
`antall`	No	Number of client requests on the engagement, internal requests excluded.
`status`	Yes	available for a visible engagement.
`sources`	No	Sources that contributed to the result.
`evidence`	No
`revly_url`	No	Link to the requests of the engagement in Revly.
`truncated`	No	True when the engagement has more than 80 requests.
`oppdrag_id`	No	Engagement ID, as text.
`operation_id`	Yes	Revly operation ID for this read, recorded in the access log.
`forespoersler`	No	Up to 80 requests, newest first. Titles, descriptions, answers and recipients are not included.
`missing_sources`	No	Sources with no record. Missing data stays visible and is never treated as a positive result.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.2/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 behavior. The description adds meaningful context beyond that: the 80-item cap, omitted fields, exclusion of internal requests, and the important semantic clarification that «Ikke vurdert» means no assessment is recorded rather than that the response is sufficient.

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?

The description is front-loaded with the core action and scope, then adds constraints and a semantic caveat in three tight sentences. The field enumeration is somewhat long relative to the output schema, but it is not bloated and every part contributes useful context.

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?

Given the existing annotations, 100% schema coverage, and an output schema, the description is complete enough for correct invocation. It covers scope, exclusions, interpretation of a key value, and the explicit-ID requirement, leaving no major ambiguity for an agent.

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%, and the single required parameter is already documented in the schema as an explicit Revly engagement ID. The description reinforces that it must be explicit but adds little syntax or format detail beyond what the schema already 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 description states a specific verb and resource: fetching client requests for one explicit engagement ID, capped at 80. It is clearly distinguishable from sibling tools such as hent_funn and hent_handlinger because it names the exact resource and scope.

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?

It gives clear usage context by requiring an explicit oppdrag-ID and stating that internal requests are excluded. However, it does not explicitly compare this tool with alternatives among the many hent_* siblings, so it falls short of full when/when-not guidance.

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

All Revly 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?