Skip to main content
Glama

Hent revisjonshandlinger fra Revly

hent_handlinger
Read-onlyIdempotent

Henter revisjonshandlingene på én eksplisitt oppdrags-ID. Svaret har alltid en eksakt oppsummering per revisjonsområde: antall, utført, i arbeid, ikke aktuell og gjennomgått, for delår og årsslutt hver for seg, planlagte forslag som venter, og områdesignering. Områder med arbeidspapir telles fra arbeidspapiret, ellers fra de eldre handlingene, som i områdeoversikten. Oppgi omraade for å få handlingene i ett område: status, om den er utført og gjennomgått med dato, handlingstype, bevismetode, påstander og ISA-nummer, høyst 100 handlinger og 30 forslag. Handlingstekst, notater, konklusjoner, begrunnelser og hvem som har utført eller signert er utelatt. Et område uten handlinger betyr «ingen registrert», aldri «ferdig». Dette er arbeidsstatus, ikke en faglig godkjenning.

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_handlinger"
  }
}

Input Schema

NameRequiredDescriptionDefault
omraadeNoOmrådekode fra per_omraade, for eksempel S for salg. Utelat for bare oppsummeringen.
oppdrag_idYesEksplisitt oppdrags-ID fra Revly. Oppslag uten ID er ikke tillatt.

Output Schema

NameRequiredDescriptionDefault
aarNoEngagement year.
statusYesavailable for a visible engagement.
omraadeNoThe area the procedure rows belong to, when one was requested.
sourcesNoSources that contributed to the result.
evidenceNo
revly_urlNoLink to the engagement in Revly.
truncatedNoTrue when the procedure rows or proposals were cut at their bound. The roll-up is never cut.
handlingerNoProcedures of the requested area, at most 100. Null when no area was requested.
oppdrag_idNoEngagement ID, as text.
per_omraadeNoExact roll-up per audit area over every procedure, never cut.
operation_idYesRevly operation ID for this read, recorded in the access log.
detalj_antallNoProcedures in the requested area; more than the rows returned when truncated.
detalj_modellNoModel of the procedure rows.
missing_sourcesNoSources with no record. Missing data stays visible and is never treated as a positive result.
planlagte_handlingerNoProposed procedures in the requested area waiting for the auditor, at most 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context on top: hard caps of 100 handlinger and 30 forslag, an explicit list of omitted fields (tekst, notater, konklusjoner, signatarer), the counting rule for areas with workpapers, and the caveat that this is arbeidsstatus rather than faglig godkjenning. This is exactly the kind of behavior an agent cannot infer from structured fields.

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?

Purpose is front-loaded in the first sentence and the response contract follows logically. It is dense but mostly earns its length; the sentence about counting from arbeidspapir versus elder handlinger is the one piece that is hard to parse without outside context.

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?

An output schema exists, yet the description still spells out the summary shape and the truncation limits, which are genuinely useful for planning. With annotations, full schema coverage and an output schema, nothing critical is missing; the only gap is the absent routing versus sibling tools.

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 both parameters are already documented, including the omraade pattern and example. The description adds only a restatement of what omraade yields, not new syntax or constraints, so the baseline 3 applies.

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?

States a specific verb+resource ('Henter revisjonshandlingene') scoped to exactly one explicit oppdrags-ID, which is precise enough for an agent to act on. It does not name any sibling tool (e.g. hent_funn, hent_oppdrag_tilstand) to disambiguate, so it stops short of a 5.

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?

'Oppgi omraade for å få handlingene i ett område' gives clear guidance on how to widen the response, and the warning that an empty area means 'ingen registrert', never 'ferdig', is genuine usage guidance. However, there is no statement of when to prefer this tool over the many sibling retrieval tools, nor any exclusion conditions.

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