Skip to main content
Glama
Sign In

Kvickd

by com.kvickd
OverviewDiscussionsAdmin

Lista kundportalen

list_kundportal
Read-onlyIdempotent

Listar kundportalen för ett bolag som sköts av en redovisningsbyrå i Kvickd: byråns förfrågningar till kunden (status oppen = väntar på kunden, besvarad = kunden har svarat eller laddat upp, klar) och underlag som kunden skickat utan förfrågan. Använd för att se vad som saknas och vad kunden har skickat in; filerna ligger också i inkorgen (list_inbox, källa kundportal) och bokförs därifrån. Returnerar per förfrågan id, rubrik, beskrivning, förfallodatum, status, antal filer och senaste aktivitet, de senaste fristående uppladdningarna med avsändarens namn och e-post, samt inmejlade underlag (för en kund bara mejl från den egna adressen) med vilka förfrågningar de är kopplade till. Läser bara, ändrar inget.

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": {
      "orgnr": "<orgnr>"
    },
    "name": "list_kundportal"
  }
}

Input Schema

NameRequiredDescriptionDefault
orgnrYesBolagets organisationsnummer, 10 siffror med eller utan bindestreck, t.ex. 559900-1004. Hämta med list_companies.
statusNoValfritt: oppen, besvarad eller klar (flera med komma). Utelämnat = alla.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations it explains what the statuses mean (oppen = väntar på kunden, besvarad = kunden har svarat eller laddat upp, klar) and discloses a real scoping rule: for a single customer only mail from that customer's own address is included. It also lists the returned fields, which matters because there is no output schema. Gaps: no indication of how many "senaste fristående uppladdningarna" are returned, ordering, or any size limits.

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?

Front-loaded with the resource and its contents, then usage, then return shape. It is a single dense paragraph and the return-value sentence is long, but nearly every clause carries information an agent needs; only "Läser bara, ändrar inget" is largely redundant with the annotations.

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?

With no output schema, the description carries the burden of describing returns and does so field-by-field, plus status vocabulary, data scoping, and the relationship to list_inbox. Combined with 100% parameter coverage and full annotations, an agent has enough to invoke this correctly on the first try.

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 above that by giving meaning to the status values rather than just listing them, so an agent understands what filtering by 'oppen' or 'besvarad' actually selects. The orgnr parameter is left to the schema, which already tells the agent to fetch it via list_companies.

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?

Specific verb + resource + scope: "Listar kundportalen för ett bolag som sköts av en redovisningsbyrå" and it enumerates the two content types (byråns förfrågningar and fristående underlag). It explicitly separates itself from the nearest sibling by noting the files also appear in list_inbox (källa kundportal), so an agent can pick the right tool without opening a schema.

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?

"Använd för att se vad som saknas och vad kunden har skickat in" gives a concrete use case, and it names the alternative (list_inbox) plus the fact that booking happens from there, which is an implicit steer away from this tool for posting. It stops short of stating explicit exclusions or prerequisites (e.g. that the company must be a kundportal/agency-managed client).

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

All Kvickd toolsInspect
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