Riksflödet

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

With no annotations, the description carries the full burden and does disclose the return contents (verbatim protocol text plus speaker, party, date and debate). It does not cover failure behavior for an invalid id or any access constraints, so it is informative but not fully transparent.

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

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

Two compact sentences with the result content front-loaded and no filler. The Swedish/English duplication is somewhat redundant but brief and serves a bilingual audience, so it costs little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter retrieval tool with no output schema, the description is sufficient: it explains what the tool returns and indirectly where the id comes from. The only gap is the absence of any when-to-use routing or error guidance, which is minor at this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter and schema coverage is 100%; the schema already documents the id format (<dok_id>-<nummer>) and its source tool. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: the verbatim full text of a single chamber speech, and enumerates exactly what it carries (speaker, party, date, debate). The singularity ('one speech', 'ett anförande') naturally distinguishes it from the search-oriented sibling sok_anforanden, so an agent can tell them apart without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended usage (retrieve one speech by its id) is clearly implied by the purpose and the required id parameter, but the description never states when to prefer this over sok_anforanden, nor that the id must first be obtained from that search. No explicit alternatives or exclusions are named.

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

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

With no annotations, the description carries the full burden. It discloses the response content (party line comparison and deviation marking) and that results can be filtered, but says nothing about default result count, pagination, or required permissions, leaving meaningful behavioral gaps for a 7-parameter tool.

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

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

The core capability and filters are front-loaded in one sentence, followed by an English restatement that is redundant for a bilingual audience but harmless. No filler beyond the translation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no required parameters, no annotations, and no output schema, the description covers intent and filters but omits defaults and the shape of the result set (e.g., whether a vote list is returned per Riksdag vote), which an agent would need to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description loosely maps its filters to parameters ("ämnesord" to fraga, "period" to fran/till, "bara avvikelserna" to bara_avvikelser) but adds no syntax or format detail, and never clarifies the relationship between namn and person_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource – how a named MP voted – and adds what is returned (party line alongside, deviation markers), which clearly separates it from votering or senaste_voteringar, which cover votes rather than a member's record. It never explicitly names a sibling, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Kan begränsas till ett ämnesord, en period eller bara avvikelserna" implies how to narrow the query, but there is no statement of when to prefer this tool over partiets_linje or votering, and no prerequisites (e.g., must supply namn or person_id).

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral: no default for the optional 'dagar' parameter, no ordering or result-limit behavior, no return shape. It essentially restates the resource rather than explaining how the tool behaves. The low-risk nature of a calendar read mitigates but does not excuse the gap.

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

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

Two short sentences, but the second is a near-verbatim English translation of the first, so roughly half the text is duplicate content that earns no additional place. The purpose is front-loaded, which helps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only calendar tool with no output schema, the description covers what the tool surfaces, which is the minimum an agent needs. It omits what happens when 'dagar' is omitted and how results are ordered, leaving real gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single bounded integer parameter, so the baseline is 3. The description adds no extra meaning about the day window or its default beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope – the parliament's forward calendar – and enumerates the event types it covers (debates, decisions, question time, committee meetings, hearings). That is far clearer than a tautology. It does not, however, distinguish itself from siblings such as senaste_voteringar or votering, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to reach for this tool versus the vote- or speech-oriented siblings, and no mention of prerequisites or exclusions. The forward-looking framing is implied by 'framåt' but never contrasted with the backward-looking tools.

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

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

With no annotations, the description carries the full burden. It helpfully discloses the return content (line, tally, defectors) but does not state whether the operation is read-only, what permissions are needed, or any limits or side effects. For a query tool this is adequate but leaves some transparency gaps.

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

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

The description is front-loaded with the core purpose and is appropriately sized. The bilingual duplication is slightly redundant but not wasteful, and the party code list is compact and useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with no output schema, the description explains what is returned well. However, it omits any explanation of the n parameter and provides no usage context, leaving the definition minimally complete but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so most parameters are documented in the schema. The description repeats the party codes already in the schema and does not explain the n parameter, which lacks a schema description. It adds little semantic meaning beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and data returned: a party's line in votes, the tally, and defector count. It clearly separates this from generic vote data, though it does not explicitly name which sibling tool to use instead. The inclusion of party codes further specifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance or alternatives are provided. The description implies the tool is for getting a party's voting line but does not explain when to choose it over siblings like hur_rostade or votering. No prerequisites or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content (outcomes plus ids) and that results are the most recent, but omits the result cap (n max 25), default ordering, and any pagination or permission behavior for what is presumably a read-only listing.

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

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

Front-loaded and single-purpose, but the Swedish and English sentences are a full restatement of the same content rather than complementary detail, effectively doubling the length without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does cover return content (votes with outcomes, ids usable by 'votering'), and it names the filter dimensions. It stops short of defining the result count/ordering, but is otherwise sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so fran, till, fraga and utskott are already documented in the schema. The description duplicates that filtering story and re-uses the same committee-code examples already present in the schema, adding little new syntax. The 'n' limit parameter is undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: the latest chamber votes, with outcomes, scopeable by keyword/committee/period. It also distinguishes itself from the sibling 'votering' by noting it yields the ids that tool consumes, and from 'kommande_i_kammaren' by covering past/current votes rather than upcoming ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context that this is the discovery/listing entry point and 'votering' is the detail fetcher ('Ger id:n som verktyget votering tar'). It does not spell out an explicit when-not-to-use or list all alternatives (hur_rostade, partiets_linje), but the primary routing decision is stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the result (talare, parti, datum, utdrag, länk), which partially compensates for the missing output schema, but it says nothing about limits, pagination, or ranking behavior beyond the schema's 'n' constraint.

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

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

Two sentences, front-loaded with the search scope and followed by the returned fields. The Swedish/English duplication roughly doubles the length but each version is tight and waste-free.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only search with no output schema, the description covers purpose and result fields adequately. The only real gaps are the absence of sibling differentiation and any note on result limits or ranking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'fraga' and 'n' are already documented in the input schema (including the Swedish-language search hint and the max of 10). The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (fritextsökning/full-text search) and resource (speeches in the Riksdag chamber) and enumerates what it returns: speaker, party, date, excerpt, link. This clearly separates it from a simple record fetch, but it never names or contrasts the sibling hamta_anforande, which also deals with speeches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by scoping the search to 'allt som sagts i kammaren', but gives no explicit when-to-use, when-not-to-use, or alternative (e.g., use hamta_anforande to retrieve a specific speech). Guidance is left to inference.

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

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

With no annotations, the description carries the behavioral burden. It usefully scopes the tool to *sitting* members/ministers and lists what is returned, but says nothing about permissions, whether partial-name lookups can return ambiguous results, or what happens with zero arguments (both params are optional).

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

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

Front-loaded with the useful resource statement, but the entire content is duplicated verbatim in Swedish and English, doubling length without adding information. Removing the redundant half would make it tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description reasonably compensates by enumerating returned fields (party, constituency, committees, voting record). However, for a lookup tool with zero required parameters it omits how ambiguity or empty argument sets are handled, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (namn, person_id) are already fully documented in the schema. The description adds no additional syntax or matching semantics, so the baseline of 3 for schema-driven parameters is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (a sitting MP or minister) and enumerates the facts returned: party, constituency, committees, tenure, voting record. That is far more concrete than a tautology, and the person-centric focus is distinct from vote/speech siblings, though the description never explicitly contrasts itself with tools like partiets_linje or hur_rostade.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no mention of alternatives or prerequisites. The only hint is the word 'sitting', which implicitly excludes former members, but the agent is left to infer when to call vem_ar versus votering or partiets_linje.

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

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

No annotations are supplied and no output schema exists, so the description carries the full burden. It does disclose the substantive return content (outcome, per-party line with tally, party defectors), which is genuinely useful, but says nothing about read-only nature, permissions, or result format.

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

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

Two compact sentences with the resource scope front-loaded and an efficient enumeration of the returned detail. The Swedish/English duplication is redundant but harmless and standard for a bilingual audience.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter retrieval tool whose output has no schema, the description adequately conveys what an agent gets back. The main omission is any linkage to the sibling tools that supply the required id or partition the same domain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage, and that schema text already explains the id and its provenance. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (retrieve one vote 'i sin helhet') and enumerates the payload: outcome, each party's line and tally, and dissenting members. This clearly distinguishes it from lighter siblings like partiets_linje or hur_rostade, though it never names those alternatives directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no when-to-use guidance or exclusion relative to the many related siblings (hur_rostade, partiets_linje, senaste_voteringar). The only routing hint lives in the input schema's parameter description, not in the tool description itself.

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