Ask your own D&D and TTRPG campaign: lore, characters, and optional pictures paid in credits.
Scored across 10 tools
Tools split cleanly by resource and action: list/find/get for characters, list/read/search for lore, separate make_*_picture tools, and check_credits. The related lore tools are distinguished by listing, searching, and reading, while character detail and character images are clearly separate.
All tool names use a consistent snake_case verb_noun pattern, such as find_characters, get_character, read_lore, and make_world_picture. The verbs vary semantically, but the convention is predictable and there is no mixed casing or vague naming.
Ten tools is a well-scoped count for a focused LoreKeeper retrieval and image-generation surface. Each tool appears to earn its place without excessive fragmentation.
Core read paths for worlds, characters, character images, and lore documents are covered, and image generation is present. However, there is no get_world for detailed world data and no create, update, or delete tools for worlds, characters, or lore, leaving notable lifecycle gaps.
Free. The person's LoreKeeper credit balance, what one picture costs, how much of today's limit for connected apps is left, and whether this connection may spend credits at all.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds two valuable facts beyond them — that the call itself is free and that the connection may be prohibited from spending credits at all. It doesn't say what happens when credits are exhausted or how the limit resets.
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?
It is short and front-loads the most decision-relevant word ('Free.') before listing the four returned facts. The list is a sentence fragment with a slightly awkward switch between 'The person's credit balance' and 'whether this connection', but no sentence is wasted.
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 carries the burden of describing return values and does so by naming all four. Minor gaps remain — units or currency of the balance, and what the limit window means — but an agent can call it correctly and interpret the result well enough.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly spends its words on return content instead.
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 enumerates exactly what the tool returns: credit balance, per-picture cost, remaining daily app limit, and whether the connection may spend credits. That is specific enough to separate it from siblings like make_character_picture, which consumes credits, though it never states the verb 'check/retrieve' outright.
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?
'Free' signals there is no cost to calling it, and the per-picture cost output implies it should be consulted before image-generation tools, but the description never explicitly says when to call it or when not to. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a world's characters (player characters and NPCs) with a
one-line summary and their character_id. name filters by name or alias (partial match). Page with
offset / limit (up to 200).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| offset | No | ||
| world_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new context: the result is a lightweight one-line summary plus id, filtering is partial-match on name OR alias, and results are paginated. It stops short of saying what happens by default (e.g., whether all characters are returned when no name is given) or total counts.
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 short sentences, front-loaded with what the tool returns before covering filtering and paging. No filler or restated title.
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?
No output schema exists, and the description compensates by describing the returned fields; annotations cover the safety profile. Remaining gaps are small but real for a 4-parameter tool at 0% schema coverage: default paging values and the required nature of world_id are unstated.
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 0%, so the description carries the load and does so for three of four parameters: name (partial match against name or alias), offset/limit (pagination, capped at 200), and world_id implicitly as the required scope. It omits defaults (limit=50, offset=0) and matching behavior like case sensitivity.
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 and resource ('List a world's characters'), scopes what is included (player characters and NPCs), and even declares the return shape (one-line summary plus character_id). The plural 'List' cleanly separates it from the singular sibling get_character.
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?
Usage is implied — you call it to enumerate a world's characters, optionally narrowed by name — but there is no explicit guidance on when to use this versus get_character (for full detail) or how it relates to get_character_images. No when-not-to-use statement is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything the person saved in LoreKeeper about one character: summary, description, look (appearance, visual reference and art style), personality, quotes, backstory, voice and roleplay notes, character sheet, and the web address of each saved image (the newest 20 in the gallery). For describing, voicing or drawing the character consistently.
| Name | Required | Description | Default |
|---|---|---|---|
| character_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral detail beyond annotations by listing the returned sections and noting that image URLs are limited to the newest 20 in the gallery; it does not cover missing-character behavior or auth requirements, but those are secondary for this read 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 description is front-loaded with the core retrieval scope and then lists the included fields efficiently. The enumeration is somewhat long but each item contributes to the agent's understanding of what is returned.
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 effectively serves as the return-value specification by enumerating the character sections and image URL limit. It is complete for safe read retrieval, though it leaves the character_id input source/format implicit.
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 one required parameter, character_id, and schema description coverage is 0%, so the description needs to explain it. The description says the tool retrieves 'one character' but never clarifies where that ID comes from, its expected format, or how to obtain it from find_characters or list results.
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 uses a specific retrieval verb and names the exact resource: everything LoreKeeper saved about one character. It enumerates the included sections and image URLs, making the scope clear and distinguishing it from broader search/list tools such as find_characters or image-only tools like get_character_images.
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 explicitly states the use case: describing, voicing, or drawing the character consistently. It does not name when to use an alternative tool or when not to use this one, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The images already saved for a character in LoreKeeper, returned as
pictures: the portrait, the reference sheet and the gallery. It returns
existing images and creates none. which is portrait, reference_sheet,
gallery or all; limit is 1-6. For a visual reference when describing
or recreating the character.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| which | No | all | |
| character_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: it asserts no images are created and characterizes the return as pictures of three distinct kinds, which the annotations cannot express.
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-loads the core purpose and the negation ('creates none') before parameter details and the use case. Slightly wordy and line-wrapped, and the use-case sentence would read better ahead of the parameter enumeration, but no sentence is wasted.
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 rightly characterizes the return (portrait, reference sheet, gallery). It is nearly complete for a three-parameter read tool; ordering when `which=all` and the interaction between `which` and `limit` are left implicit.
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 0%, so the description must carry the parameter burden, and it does: it enumerates the legal values of `which` (portrait, reference_sheet, gallery, all) that the schema leaves as an unconstrained string, and states the `limit` range of 1-6. Only `character_id` is left unstated, which is self-evident from the name.
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?
Names a specific verb and resource ('images already saved for a character in LoreKeeper') and enumerates the returned artifacts: portrait, reference sheet, gallery. It also explicitly distinguishes itself from the picture-making sibling by saying it 'returns existing images and creates none'.
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?
Gives a concrete use case ('For a visual reference when describing or recreating the character') and a negative boundary that implicitly routes the agent to make_character_picture when it needs new images. It does not name that sibling explicitly, so the routing is clear but inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the documents in a world's Lore Library, grouped by folder, with
their document_id. folder filters by folder name (partial match).
Page with offset / limit (up to 200).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | ||
| offset | No | ||
| world_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context: results are grouped by folder, document_id is included, folder matching is partial, and limit is capped at 200. It does not disclose ordering or exact response shape, but annotations lower the burden.
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 three sentences, front-loaded with the core action, and every sentence adds useful detail. There is no redundant or filler text.
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 four-parameter list tool with no output schema, the description is largely complete: it covers listing behavior, folder filtering, pagination, and document_id inclusion. It leaves minor gaps around world_id semantics and result ordering, but annotations cover the safety profile.
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 0%, so the description must compensate for four parameters. It explains folder as a partial-match filter and offset/limit as paging with a maximum of 200, but it does not explicitly describe the required world_id parameter beyond the phrase 'a world's Lore Library'.
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 uses a specific verb and resource: list documents in a world's Lore Library. It also states that results are grouped by folder and include document_id, making the operation clear. However, it does not explicitly distinguish this from siblings like search_lore or read_lore.
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 explaining folder filtering and pagination, but it does not say when to use list_lore instead of search_lore or read_lore. There are no explicit exclusions or alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the person's LoreKeeper worlds (their D&D and other tabletop RPG campaigns and settings) with a one-line summary and the world_id that every other tool takes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not burdened with that. It adds value beyond annotations by disclosing the return shape — one-line summary and world_id — which matters since no output schema exists. It does not mention pagination, ordering, or behavior when the person has no worlds, leaving a small 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?
A single sentence with the resource and the returned fields front-loaded; every clause adds information (resource meaning, return content, downstream key). No filler.
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 zero-param read tool with rich annotations but no output schema, the description covers purpose and return content adequately. Empty-state behavior and ordering are unstated but are minor omissions for a list call.
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 tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. The description correctly implies no filtering or scoping inputs are needed.
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 and resource ('List the person's LoreKeeper worlds') and immediately disambiguates the term with a parenthetical defining worlds as D&D/tabletop RPG campaigns and settings. It also specifies the payload (one-line summary plus world_id), so the agent knows exactly what comes back.
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 phrase 'the world_id that every other tool takes' implicitly positions this as the discovery entry point before using sibling tools, which is clear context for invocation ordering. There is no explicit when-not guidance, but with no overlapping sibling (all others operate on characters or lore) there is little ambiguity to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Costs 150 LoreKeeper credits: say so and ask first. Makes a new picture of one of the person's characters in their world's art style, drawn from the character's look and visual reference, and adds it to the character's gallery. description: what the picture should show (a scene, a pose, an outfit); empty for a plain new picture. portrait=true also makes it the character's portrait (the old one stays in the gallery). shape: square, portrait or landscape. Returns the picture and its web address.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | ||
| portrait | No | ||
| description | No | ||
| character_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses the 150-credit cost, the need to ask for confirmation, that a new picture is added to the gallery, and that setting portrait=true preserves the old portrait in the gallery. It also states the return value: the picture and its web address.
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 cost and consent requirement, followed by purpose, parameter semantics, side effects, and return value. It is dense and each sentence adds useful 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?
Given no output schema and only minimal schema descriptions, the description covers the critical cost, consent, behavior, side effects, and return value. It is complete enough for an agent to invoke the tool correctly with appropriate user confirmation.
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 0%, so the description must carry parameter meaning. It explains description, portrait, and shape well, including the effect of portrait=true and allowed shape values, but it does not explain character_id or how to obtain it.
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 gives a specific verb and resource: it 'makes a new picture of one of the person's characters' in the character's world art style and adds it to the character's gallery. This clearly distinguishes it from sibling image tools such as make_world_picture and get_character_images.
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 provides important usage context: the tool costs 150 LoreKeeper credits, so the agent must tell the user and ask first. It also explains when to use description versus leaving it empty. However, it does not explicitly route the agent to alternatives like make_world_picture for world images or find_characters for character IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Costs 150 LoreKeeper credits: say so and ask first. Makes a new picture for one of the person's worlds (a place, a scene, a moment) in the world's art style and adds it to the world's gallery. description: what it should show. shape: square, portrait or landscape (the default). Returns the picture and its web address.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | ||
| world_id | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic non-read-only, non-idempotent profile; the description adds the concrete cost (150 credits), the required confirmation step, the persistent side effect (image is appended to the world's gallery), the style inheritance, and the return value. That is substantive disclosure beyond the annotation set, and nothing contradicts readOnlyHint=false.
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?
Cost and consent are front-loaded in the first clause, then purpose, then per-parameter notes, then return value. Each sentence adds new information with no repetition of the schema or annotations.
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 helpfully states what comes back (the picture and its web address), and it covers cost, style and persistence. What remains thin is the identity of `world_id` and any failure behavior (e.g. insufficient credits), so it is complete but not exhaustive.
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 0%, so the description carries the full burden. It explains `description` ('what it should show') and `shape` with its three values and the landscape default, but `world_id` is never mentioned, leaving the required key parameter undocumented.
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 and resource ('Makes a new picture for one of the person's worlds'), plus scope ('a place, a scene, a moment') and outcome ('adds it to the world's gallery'). The world framing cleanly separates it from the sibling make_character_picture without either schema being opened.
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?
Gives explicit behavioral instructions for invoking it: it costs 150 credits and the agent must 'say so and ask first' — a real precondition, not implied. It lacks an explicit when-not statement (e.g. insufficient credits, or world vs character subject), which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one Lore Library document in full, a page at a time. A page of a long document ends with a cursor; passing that cursor returns the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds genuinely new behavioral context: responses are paginated, a truncated page terminates with a cursor, and supplying that cursor yields the next page. It omits cursor expiry and not-found behavior, keeping it from a 5.
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 tight sentences with zero filler. The core action is front-loaded and the pagination rule follows immediately as the only caveat that matters.
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?
No output schema exists, yet the description conveys the shape of a result (document content plus an optional trailing cursor) and implies that absence of a cursor means the document ended. It does not cover failure modes such as an invalid or expired cursor, which is the remaining gap for a 2-parameter read tool.
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 0%, so the description must carry parameter meaning. It explains the non-obvious 'cursor' parameter end-to-end (where it comes from and what passing it does), which is the only parameter needing explanation; 'document_id' is self-evident from 'Read one ... document' but is never stated explicitly.
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 ('Read') and resource ('one Lore Library document in full'), and the phrase 'one ... document' implicitly contrasts with the sibling list_lore and search_lore tools. It stops short of naming those siblings, so an agent must infer the distinction.
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?
Usage is implied: fetch a single document by id, and pass a cursor to continue. There is no explicit statement of when to prefer this over search_lore or list_lore, nor any exclusion or prerequisite (e.g. needing a valid document_id from a prior list/search call).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the passages in one world's Lore Library (the person's own campaign
notes, session recaps and setting documents) that best answer a question
or match a topic: people, places, factions, history, house rules, what
happened in a session. Returns up to limit passages (1-12), each with
its document title and document_id. Works best with a focused question;
a broad topic may take several searches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| world_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description still earns credit by disclosing the result cap and shape ('up to limit passages, each with its document title and document_id'), the single-world scoping constraint, and the retrieval caveat about broad topics. It omits behavior for zero-result searches and ranking details.
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?
Four sentences, front-loaded with the operation and scope, then content coverage, then return shape, then the practical query tip. No filler, no repetition of the title or annotations.
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 and 0% schema description coverage across 3 params, the description closes most of the gap: return shape, result cap, single-world scope, and query strategy are all stated. A note on empty results or how document_id should feed into read_lore would make it fully complete for chaining.
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 0%, so the description carries the full burden and does add meaning: it gives the limit range (1-12, beyond the bare default of 6) and implies world_id restricts search to one world's library and that query should be a focused question rather than a broad topic. It does not explain what happens for out-of-range limit values or the world_id format.
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 (search/find passages) on a specific resource (one world's Lore Library), and the 'best answer a question or match a topic' framing makes clear this is relevance-ranked retrieval rather than enumeration (list_lore) or full-document fetch (read_lore). It also enumerates the content types it covers (campaign notes, session recaps, setting documents) and the entities it indexes (people, places, factions, history, house rules).
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?
Gives concrete usage advice: 'Works best with a focused question; a broad topic may take several searches,' which tells the agent how to phrase queries and that multiple calls are expected. It never names alternatives (list_lore, read_lore) or states when not to use it, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_creditsfind_charactersget_characterget_character_imageslist_lorelist_worldsmake_character_picturemake_world_pictureread_loresearch_loreCharacters, campaigns, adventures & worlds for D&D 5e/5.5e, Pathfinder, Savage Worlds, Fate, & more.
D&D and TTRPG campaign manager for GMs: your AI reads and writes a live, typed campaign database.
Tabletop RPG campaign wiki for game masters: NPCs, places, sessions, encounters, notes, roll tables
Manage your tabletop RPG campaign from any MCP client: worlds, sessions, quests, lore, recaps.
Add one secure layer between your agents and this server.
