list_topicsCurated obligation topics ('Pre-contract information') under a subject head, each with a one-paragraph orientation and per-jurisdiction anchor counts. Descriptions with editorialStatus='draft' are UNREVIEWED model drafts — say so if you quote one. Feed a result's conceptId to get_topic.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Subject head concept id, e.g. 'local:consumer'. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavior: results may include UNREVIEWED model drafts marked editorialStatus='draft', and the agent should disclose this when quoting. This is valuable non-obvious context beyond the structured annotations.
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?
Three sentences, each earning its place: the first states purpose and result contents, the second warns about draft quality, and the third gives the next-step routing. The most decision-relevant information is front-loaded.
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 list tool with no output schema, the description covers what is returned (topics, orientation, per-jurisdiction counts), flags the draft-status caveat, and tells the agent what to do next. Nothing critical is missing for correct invocation or handling of results.
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?
The schema describes subject as a 'Subject head concept id' with an example, and the description similarly refers to 'under a subject head'. With 100% schema coverage, the description adds no substantive new parameter meaning beyond reinforcing the concept, 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?
The description opens with a specific verb and resource: listing 'curated obligation topics' under a subject head. It also names the result contents and points to get_topic as the follow-up tool, which distinguishes it from that sibling without needing to inspect schemas.
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?
It clearly implies use with a subject-head concept id and gives a workflow cue: feed a result's conceptId to get_topic. However, it does not explicitly state when not to use this tool or compare it against siblings like provisions_by_concept or search_legislation, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, and descriptions carefully separate overlapping areas such as definition lookup, cross-references, and transposition links. A few citation/graph tools (related_works, work_mentions, find_national_implementations, provision_context) could be confused at a glance, but their granularity and direction are explicitly differentiated.
Naming follows a readable all-lowercase-snake_case style, but conventions are mixed: roughly half are imperative verb_object names (lookup_provision, search_legislation, list_topics) while the rest are bare noun-phrase view names (provision_context, recent_changes, work_mentions). The pattern is understandable but not uniform.
At 18 tools, the set is slightly above the ideal 3-15 range, but each tool maps to a distinct research query or data product. The count is justified by the breadth of legal-research operations rather than redundancy.
The surface covers the domain thoroughly: search, provision lookup, definitions, multilingual terms, cross-references, amendment history, transposition links, topics, coverage, updates, and review workflows. The explicit read-only design means absent write operations are a deliberate boundary, not a gap.