Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kanka MCP Server List my campaigns"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local MCP tool for the Kanka worldbuilding API. Runs on your machine via stdio — no remote server needed.
Node.js 20+.
A Kanka API token (get one at kanka.io/en/settings/api).
Related MCP server: kanka-mcp
npm installAdd this to your MCP client config:
{
"mcpServers": {
"kanka": {
"command": "node",
"args": ["<ABSOLUTE_PATH_TO_REPO>/index.js"],
"env": {
"KANKA_API_TOKEN": "<YOUR_KANKA_TOKEN>"
}
}
}
}Notes:
Replace <ABSOLUTE_PATH_TO_REPO> with the full path to this repository.
On Windows, prefer forward slashes (C:/Users/...) or escaped backslashes (C:\\Users\\...).
Restart the MCP client after editing the config.
KANKA_API_TOKEN=your_token npm startnpm install -g .
KANKA_API_TOKEN=your_token kanka-mcpThe tool exposes 82 MCP tools for interacting with Kanka:
list_campaigns — List all campaigns
search — Search entities within a campaign
For each entity type (Character, Location, Family, Organization, Item, Note, Event, Calendar, Timeline, Creature, Race, Quest, Map, Journal, Ability, Entity):
list_<entities> — List all
get_<entity> — Get details
create_<entity> — Create new
update_<entity> — Update existing
delete_<entity> — Delete existing
Community contributions are welcome.
Read CONTRIBUTING.md for workflow, coding standards, and PR checklist.
Review CODE_OF_CONDUCT.md before participating.
npm run lint
npm run format:check
npm testCreate a new ability
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create a new ability.' It fails to mention required campaign context, side effects, idempotency, auth requirements, or what happens on success.
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 short but under-specified; the single sentence merely restates the tool's name and purpose without adding value. True conciseness would front-load critical details like the required campaignId and the expected structure of data.
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 two required parameters, a nested data object, no output schema, and no annotations, this description is completely inadequate. An agent cannot determine what to pass for data, what campaignId refers to, or what a successful creation returns, making the tool effectively unusable from the description alone.
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%, and the description provides no explanation of either parameter. The 'data' property is an untyped object with no defined shape, and 'campaignId' has no semantic meaning attached, leaving the agent unable to construct a valid request.
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 'Create a new ability' clearly states a specific action and resource, distinguishing it from get_ability, update_ability, delete_ability, and list_abilities. However, it offers no detail about what an ability is in this domain, so it lacks explicit differentiation from the many other create_* sibling tools.
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 guidance is provided on when to use this tool versus alternatives like update_ability or create_character. The intended use case must be inferred entirely from the tool name, with no exclusions or conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new calendar
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only restates the creation operation already implied by the tool name. It does not mention persistence side effects, campaign association, permissions, validation, or return behavior.
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 one-sentence description is short and readable, but the brevity is under-specification for a tool with two required parameters and a nested data object. It lacks enough substance to count as appropriately sized for the tool's complexity.
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, no annotations, and 0% schema description coverage, this one-line description is the agent's only guidance, and it explains nothing about required inputs, behavior, or success criteria. For a create operation with required campaignId and data, this is materially incomplete.
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%, yet the description names neither campaignId nor data. An agent gets no clue that campaignId likely identifies the campaign to add the calendar to, or what shape the nested data object should take.
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 clear action ('Create') and a clear resource ('a new calendar'), so an agent can tell this tool creates a calendar as opposed to listing, updating, or deleting one. However, it mostly paraphrases the tool name and does not distinguish it from other create_* siblings such as create_timeline or create_event.
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 guidance about when to use this tool versus list_calendars, update_calendar, delete_calendar, or related create tools. No prerequisites are mentioned, such as requiring an existing campaignId. The intended invocation context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new character
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only states that a character is created. It does not disclose mutation/side effects, validation requirements, whether the creation is tied to a campaign, or any irreversible consequences.
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 a single sentence with no filler or redundancy; it is concise and front-loaded. However, the extreme brevity leaves out details that would make the tool more usable.
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 mutation tool with no annotations, no output schema, and two utterly undocumented parameters, this description is far too incomplete. An agent has no information about the required nested data object, the meaning of campaignId, or expected behavior on success or failure.
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% and the description adds no meaning to either parameter. 'Create a new character' does not explain what campaignId refers to or what shape the data object must take, leaving an agent unable to construct a valid call.
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 action (create) and resource (character), making the tool's basic function clear. It does not add scope details or differentiate from sibling create_* tools beyond the resource name, 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?
No guidance is given about when to use this tool versus alternatives such as update_character or when campaignId is required. The intended use is barely implied by the verb 'Create', but no context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new creature
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
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 only restates that a creature is created and does not disclose what happens with the required campaignId/data, whether the operation is reversible, what response to expect, or any validation or permission concerns.
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 extremely short and front-loaded with no filler, but it is closer to under-specification than effective concise documentation. Every word earns its place, yet the overall content is not appropriately sized for a tool with a nested data object and no 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?
For a mutation tool with no annotations, no output schema, and an opaque nested data parameter, this description is inadequate. It names the resource and action but leaves almost all invocation details unspecified, so an agent cannot reliably construct a correct 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?
Schema description coverage is 0%, and the description mentions neither campaignId nor data. The description adds no meaning beyond the schema's bare property names, leaving the agent unable to understand what data should contain or how campaignId relates to the new creature.
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: 'Create a new creature.' It is clear about the operation and entity, though it does nothing to differentiate itself from sibling create_* tools beyond the resource noun in its own name.
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 guidance is given about when to use this tool versus alternatives, when not to use it, or what prerequisites exist. With many sibling create_* tools, an agent receives no routing help beyond the resource name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new event
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a new event is created, omitting side effects, required campaign context, permissions, idempotency, or data structure expectations.
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 short but this is under-specification rather than effective conciseness. It omits essential information about required parameters and data structure, making the brevity a liability.
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?
This is a creation tool with a required nested object, no output schema, no annotations, and no parameter documentation. A single sentence restating the tool name is far from sufficient for an agent to safely invoke it.
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%, and the description does not mention either parameter. The bare schema types 'number' and 'object' give no meaning for campaignId or the nested data object, so an agent cannot construct a correct call.
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 'Create a new event' is essentially a restatement of the tool name. It identifies the action and resource but provides no additional specificity or differentiation from the many sibling create_* tools.
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 usage context or alternative guidance is provided. An agent can only infer from the name that this tool creates an event, with no indication of when to prefer it over update_event, delete_event, or other creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new family
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new family' discloses only that this is a creation operation and says nothing about side effects, required campaign context, validation behavior, or response format. This is a significant transparency gap for a mutation 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 short and front-loaded, but it is under-specified rather than usefully concise. It essentially restates the tool name and contributes no additional semantic value, so the brevity works against it.
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 two required parameters, a nested 'data' object, no output schema, and no annotations, the description is far too sparse to enable a confident invocation. An agent would not know what to put in 'data,' whether campaignId must reference an existing campaign, or what the API returns. The description provides only the high-level purpose, not enough to call the tool 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 description coverage is 0%, and the description does not mention either parameter. 'campaignId' is nominally understandable as a campaign identifier, but 'data' is left as an opaque object with no indication of what fields or structure are expected. The description fails to compensate for the lack of schema detail.
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 clear verb and resource: 'Create a new family.' It clearly indicates a creation operation and distinguishes itself from the get_family, update_family, and delete_family siblings. However, it is a near-paraphrase of the tool name and adds no detail about what a family is or what creating one entails.
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 guidance about when to use this tool versus alternatives, nor any mention of prerequisites such as needing an existing campaign. The only usage signal is the word 'create,' which is implied by the tool name itself. This is effectively no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new item
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that a new item is created, but does not explain the mutation's effects, side effects, required campaign context, validation behavior, or ownership implications.
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 short, but it is under-specified rather than appropriately concise. It repeats the tool name's meaning and fails to earn its place by adding any decision-relevant information beyond the name.
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 the absence of annotations, an opaque nested parameter, and the large set of sibling CRUD tools, this description is insufficient for an agent to confidently select and correctly invoke the tool. It does not address what data should be supplied, how campaignId relates, or what the creation entails.
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 input schema has 0% description coverage and the description adds no explanation for 'campaignId' or 'data'. In particular, the nested 'data' object is completely opaque, and the description provides no hints about its expected structure or relationship to the campaign.
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 ('Create a new item'), clearly identifying the operation as item creation. It is distinguishable from sibling create_* tools by resource type, though it offers no further differentiation or context about what an 'item' specifically entails.
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 guidance about when create_item should be used instead of the many related create_* tools, nor are any prerequisites or contexts mentioned. The description is purely a statement of action with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new journal
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the mutation ('create a new journal') and says nothing about side effects, required ownership (campaignId), or what the response will be. This is minimally transparent and leaves the agent to infer the behavior of a create operation.
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 short and front-loaded with the verb, with no wasted words. However, it is under-specified even for a simple tool, so the brevity is not a fully appropriate size and does more to obscure than to clarify.
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 two required parameters (one an undocumented nested object), no output schema, and no annotations, the tool needs a much richer description to be callable by an agent. The single sentence is nowhere near complete for deciding how to construct a correct request.
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 input schema exposes campaignId and data with zero description coverage, and the description mentions neither parameter. The agent cannot tell what campaignId refers to, what shape data should take, or why both are required; the description adds no meaning beyond the raw schema.
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 'Create a new journal' states a clear verb and resource, so an agent can identify the basic operation. However, it essentially paraphrases the tool name and gives no detail about what a journal is or what differentiates this create operation from the many other create_* siblings.
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 guidance on when to use this tool versus alternatives such as create_character, create_note, or update_journal, and no prerequisites or context for journal creation are given. The only usage signal is the bare infinitive 'Create,' which provides no strategic direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new location
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only communicates that this is a write operation; it does not describe side effects, campaign scoping, validation, duplicate handling, or return behavior.
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 short and front-loaded with no wasted words. However, the brevity is achieved by omitting substance rather than by condensing meaningful guidance.
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 two required parameters, a nested object, no output schema, and no annotations, the description is drastically incomplete. A usable definition would need to explain campaignId, the data payload shape, and what the tool returns.
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%, and the description mentions neither campaignId nor data. The data parameter is an opaque object, so the agent cannot determine what fields or structure are expected.
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 is a near word-for-word restatement of the tool name: 'create_location' becomes 'Create a new location'. It is not misleading, but it adds no extra scope, detail, or sibling differentiation beyond simply repeating the operation and resource.
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 guidance about when to use this tool versus updating or fetching an existing location, nor any mention of prerequisites such as needing a valid campaignId. Usage is only implied by the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new map
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden, but 'Create a new map' only states the action. It does not mention side effects, permissions, failure modes, reversibility, or what happens on duplicate creation.
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 very short and contains no wasted words, making it concise. However, it is under-specified for a tool with a required nested object parameter and would benefit from more structure and detail.
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 two required parameters including a nested object, no output schema, and no annotations, the description is severely inadequate. It fails to explain what 'data' should contain, why campaignId is needed, or what the operation returns, making it nearly impossible for an agent to invoke 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 description coverage is 0% and the description does not mention either 'campaignId' or 'data' at all. The unstructured 'data' object is completely unexplained, so an agent has no idea what content to supply.
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 the specific action 'create' on the 'map' resource, which clearly separates it from get_map, update_map, delete_map, and list_maps. However, it lacks any scope or distinguishing detail beyond the resource name, so it doesn't fully clarify what a map is in this context.
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 guidance is provided about when to use this tool versus any of the many sibling create_* tools, and no prerequisites such as an existing campaign are mentioned. The description offers no alternatives, exclusions, or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new note
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. 'Create a new note' only restates the action and reveals nothing about persistence, side effects, required permissions, or return behavior. It adds no informative detail beyond the tool name.
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 text is brief, but that brevity reflects under-specification rather than effective conciseness. A single uninformative sentence that fails to address the required parameters is not appropriately sized for a tool of this complexity.
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 two required parameters, no output schema, and no annotations, the description is severely incomplete. It omits the apparent relationship between notes and campaigns, the structure of data, and any invocation context. An agent would be guessing at critical input requirements.
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%, and the description does not explain campaignId or the 'data' object at all. An agent cannot determine what the data object should contain or how it relates to the campaignId parameter. The description adds zero meaning beyond the raw schema.
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 ('create') and resource ('note'), which distinguishes it from update_note/delete_note and from create tools for other resource types. It lacks any mention of campaign scoping, but the core purpose is clear enough.
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 guidance on when to use create_note versus get_note/update_note/delete_note, nor any mention of prerequisites such as needing an existing campaign. The description provides no context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new organization
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely restates the tool name. It does not mention that this is a write operation tied to a campaign, how the data object is used, whether the operation is idempotent, or what effect it has on existing resources.
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 short, which is good for conciseness, but it is under-specified rather than efficiently complete. It adds no value beyond the tool name and provides no structure for the required inputs.
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?
The tool has no annotations, no output schema, a nested data object, and zero schema description coverage. A one-line restatement of the tool name is far too little for an agent to correctly construct a call or understand the expected request shape.
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%, and the description contains no parameter information. It does not explain that campaignId identifies the campaign or that data contains the organization payload, leaving the agent without meaningful guidance for two required parameters.
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 clear action and resource: 'Create a new organization'. It is unambiguous about what entity is being operated on, but it does not actively distinguish itself from the many other create_* sibling tools beyond relying on the resource name.
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 it should be used when creating a new organization, especially in contrast with update_organization and delete_organization. However, it gives no explicit context, prerequisites, or guidance about when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new quest
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only conveys that the tool creates a quest and provides no information about side effects, required parent entity, validation, permissions, or error behavior. The description does not contradict any annotation because none exist.
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 a single short sentence with no redundant wording, but it essentially restates the tool name and adds no substantive information. This is under-specification rather than effective conciseness.
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?
The tool requires a campaignId and a nested data object, has no output schema, and has no annotations. The description is far too sparse to allow an agent to call this tool correctly; it gives no indication of the data structure, the relationship to a campaign, or what a successful response looks like.
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%, and the description does not mention either parameter (campaignId or data). Since data is a nested object and campaignId is a required number, the agent receives no help understanding what values to provide or what the data object should contain.
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 action ('Create') and resource ('quest'), which clearly distinguishes it from read/update/delete siblings. However, it adds no additional qualification about what a quest is or how it relates to campaigns, so it is clear but minimal.
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 guidance is provided on when to use this tool versus update_quest or delete_quest, nor is there any mention that a campaign must already exist. The agent must infer usage entirely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new race
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Create a new race' and says nothing about side effects, permissions, idempotency, required campaign context, or what happens on success or failure.
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 short but it is under-specified rather than concise. The single phrase earns its place only by restating the function name, offering no substantive information to the agent.
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 a required nested 'data' object, no output schema, no annotations, and zero schema descriptions, the description fails to provide basic invocation context. An agent cannot determine what data structure to send or what the response will be.
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% and the description adds no meaning to the parameters. The required 'data' object and 'campaignId' are completely undocumented, so an agent has no idea what to pass.
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 'Create a new race' simply restates the tool name 'create_race' with no additional detail. It identifies the action and resource, but is purely tautological and does not differentiate this tool from the many other create_* siblings beyond the embedded resource name.
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 guidance is provided on when to use this tool versus alternatives. With a large sibling set including get_race, update_race, delete_race, and other create_* tools, the description offers no context or exclusionary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new timeline
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure, but it only states the operation type (create) without mentioning side effects, requirements, or what happens to the nested data object. It is not misleading, but it provides no meaningful transparency beyond the action itself.
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 short, but brevity here is under-specification rather than effective conciseness: the single sentence merely restates the tool name and provides no useful details. It is appropriately front-loaded but does not earn its place with additional value.
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 creation tool with two required parameters, one of which is an opaque nested object, and no output schema or annotations, the description is far too thin. An agent cannot determine what data to provide, how campaignId is used, or what a successful timeline creation entails.
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 by explaining what campaignId and data mean; it addresses neither parameter. The nested data object is completely unexplained, leaving the agent without enough information to construct a valid call.
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 merely restates the tool name ('Create a new timeline' adds no information beyond create_timeline), so it is a tautology rather than a distinguishing definition. It identifies the verb and resource but does not clarify what a timeline is or how it differs from other timeline-related tools.
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 guidance on when to use this tool versus alternatives such as update_timeline or delete_timeline, or whether any prerequisites apply. The correct usage must be inferred entirely from the tool name and the CRUD pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing ability
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'delete', which implies a destructive action, but does not state whether deletion is permanent, idempotent, cascading, or what happens when the ability does not exist.
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 short and wastes no words, but it is under-specified rather than usefully concise. It is essentially a restatement of the tool name and provides no structural information about parameters or usage.
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 destructive tool with no annotations, no output schema, and undocumented parameters, the description is insufficient. It lacks any mention of irreversibility, side effects, or related lookup tools, leaving an agent without enough context to call it safely.
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%, and the description does not mention or explain either parameter. The presence of 'id' and 'campaignId' as bare numbers is ambiguous; the description adds nothing to help an agent understand their roles or 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?
The description 'Delete an existing ability' is a direct restatement of the tool name 'delete_ability'. It names a verb and a resource, but adds no information beyond what the name already conveys, and does not distinguish it from the many sibling delete_* tools.
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 guidance is provided on when to use this tool versus alternatives such as get_ability or update_ability. There are no stated prerequisites, exclusions, or suggestions for verifying the ability before deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing calendar
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Delete an existing calendar.' It does not state whether the deletion is permanent, irreversible, or whether it cascades to associated events or other data. For a destructive operation, this lack of transparency is a significant 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?
The description is a single sentence with no filler words, and the core action is front-loaded. It is concise and easy to parse, though the brevity contributes to the lack of context in other dimensions. It earns its place but could have been expanded with minimal cost.
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 destructive tool with no annotations, no output schema, and two undocumented parameters, this description is insufficient. It does not explain how to identify the target calendar, what the consequences of deletion are, or what the expected response is. An agent would need to guess or consult other sources to call this 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 description coverage is 0%, and the description provides no information about the parameters 'id' and 'campaignId.' An agent cannot determine which ID is which or how they relate to the calendar being deleted, so the description adds no meaning beyond the raw parameter names.
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 clearly states a specific verb ('Delete') and resource ('calendar'), which distinguishes it from sibling tools like create_calendar, update_calendar, get_calendar, and list_calendars. It is straightforward and leaves no doubt about the tool's core function, though it adds no detail beyond the operation itself.
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 guidance on when this tool should be used versus alternatives, no mention of prerequisites (e.g., needing the calendar ID and campaign ID), and no exclusion cases. The description simply names the action without contextualizing when it is appropriate or when a different tool might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing character
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses that the action deletes a character, but it does not state whether the deletion is permanent, whether it cascades to associated data, whether it requires special permissions, or what happens after deletion.
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 a single concise sentence with no redundant wording. However, it is under-specified: it basically restates the tool name and omits important context, so the brevity comes at the cost of usefulness.
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 destructive tool with no output schema and no annotations, the description is not complete enough. It fails to explain required identifiers, deletion semantics, side effects, or any safety considerations, leaving an agent under-informed before 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 0%, so the description must compensate, but it adds no parameter-level meaning. It implies that 'id' identifies the character, but 'campaignId' is left completely unexplained, leaving the agent to guess how the campaign scope affects the deletion.
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: 'Delete an existing character'. It clearly communicates the operation and distinguishes it from sibling tools like create_character, update_character, and get_character, though it does not explicitly contrast itself with them.
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 guidance on when to use this tool versus alternatives, or any mention of requirements such as the character being associated with a specific campaign. The intended use is only implied by the verb 'Delete' and the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing creature
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly indicates a destructive mutation, but says nothing about whether deletion is permanent, what happens if the creature does not exist, or whether related data is affected. This is a significant gap for a delete operation.
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 very concise with no wasted words, but it is under-specified. It earns a middle score because brevity is present, but the structure does not include important context that an agent would benefit from.
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 that there is no output schema and no annotations, the description is not complete enough for a delete operation. It does not explain the required campaign context, the effect of the operation, error behavior, or what the agent should expect after a successful deletion.
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%, and the description provides no explanation of the 'id' or 'campaignId' parameters. The parameter names are somewhat self-explanatory, but the description does not clarify which id refers to the creature, why campaignId is required, or how the two parameters relate.
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 action ('Delete') and a specific resource ('existing creature'), clearly distinguishing it from get_creature, create_creature, update_creature, and list_creatures. It is concise and unambiguous, though it adds little beyond the tool name.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or consequences. It is implied that deletion is the right operation when a creature should be removed, but the description does not make the usage context explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing event
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' conveys that this is a destructive operation, but the description does not state whether deletion is permanent or irreversible, whether it cascades to related data, whether special permissions are required, or what happens if the event does not exist. There is no contradiction with annotations since none are present, but disclosure is minimal.
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 five words with zero filler and the core action is front-loaded. It is efficiently brief, though the brevity is partly a product of under-specification rather than a deliberately compact rich definition.
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 destructive tool with two undocumented parameters, no annotations, and no output schema, this description is inadequate. It fails to clarify parameter semantics, permanence of deletion, or error behavior, leaving an agent unable to confidently invoke the tool correctly despite the simple interface.
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 by explaining what 'id' and 'campaignId' mean and how they relate. It does neither — the description mentions no parameters at all. An agent cannot determine what values to supply or whether campaignId scopes the 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 uses a specific verb ('Delete') and a clear resource ('event'), which immediately distinguishes it from sibling tools like create_event, update_event, get_event, and list_events. The word 'existing' also correctly scopes the action to pre-existing records. It is slightly minimal, but the purpose is unambiguous.
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 guidance is given about when to use this tool versus alternatives such as update_event, nor about prerequisites like the event having to exist in the given campaign. The only usage signal is implicitly derived from the verb 'delete,' which does not constitute explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing family
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only restates the delete operation and does not mention irreversibility, cascading effects, authorization needs, or whether deletion is scoped by campaignId.
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 a single short sentence with no filler, but it is under-specified rather than appropriately concise. It omits parameter roles and behavioral context that are essential for correct invocation.
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 two-parameter destructive operation with no output schema and no annotations, this description is insufficient. The agent cannot determine how to populate campaignId or what consequences deletion has, despite the overall CRUD context provided by sibling tool names.
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% and the description provides no meaning for the id or campaignId parameters. Both are bare number fields, so the agent cannot tell which is the family identifier and which is the campaign scope from the description alone.
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 clear verb and resource: it deletes a family. It does not add detail that distinguishes it from sibling delete tools beyond the resource name, but for a CRUD delete the purpose is unambiguous.
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 guidance is given on when to use this tool versus alternatives such as delete_character or update_family. The description does not mention required context such as campaignId or any preconditions, so usage context is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing item
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Delete' implies destructive mutation, but the description does not state whether deletion is permanent, whether related records are affected, or whether special permissions are required. This is a significant gap for a destructive operation.
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 concise and to the point, but it is under-specified rather than efficiently informative. It earns a middle score because there is no wasted text, yet the brevity omits essential detail.
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 annotations, no output schema, and zero parameter documentation, the tool requires more context than a one-sentence description provides. The description is complete only for the most trivial understanding of the operation and lacks details about response behavior, side effects, or parameter semantics.
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%, and the description names neither parameter. The schema shows two numbers (id and campaignId) but the description does not explain that both are required or clarify the relationship between them (e.g., campaignId scopes the item). Because coverage is zero and the description adds nothing, it fails to compensate.
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 clear verb ('Delete') and resource ('existing item'), so an agent knows the basic operation. However, it does not distinguish this from delete_character, delete_location, or other delete_* siblings, and 'item' could be ambiguous without the sibling list context. It is minimally adequate but lacks specificity about which sibling it complements.
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 guidance on when to use this tool versus alternatives like delete_character or delete_note. The description simply states what it does without any context, prerequisites, or exclusions. An agent must infer usage purely from the tool name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing journal
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Delete an existing journal' confirms the destructive nature but adds no detail about irreversibility, cascading effects, or failure behavior. The word 'existing' weakly implies the journal must be present, but this is minimal for a destructive operation.
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 five-word sentence with no filler. The verb 'Delete' leads, followed by the resource. It is appropriately concise for a simple CRUD operation, though it sacrifices explanatory content for brevity.
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 low-complexity delete tool with no output schema and no annotations, the description states the core action but leaves parameter explanations and behavioral caveats unaddressed. An agent cannot determine the role of campaignId or know whether deletion is reversible. The description is not complete enough for an unassisted agent to invoke the tool with confidence.
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 provides only numeric names id and campaignId with no descriptions, and the description adds no parameter information. The parameter names suggest id identifies the journal and campaignId scopes it, but the description does not clarify their roles or why both are required. With 0% schema description coverage, the description should compensate but does not.
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 'Delete an existing journal' clearly identifies the action (delete) and resource (journal), making it easy to distinguish from create/update/get journal siblings. It adds the qualifier 'existing', which hints that the journal must already exist. However, it relies entirely on the verb for differentiation and does not add scoping or consequence detail.
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: use this tool when a journal needs to be deleted. There is no explicit when-to-use guidance, nor mention of conditions, prerequisites, or alternatives. It also does not note that deletion is permanent or that campaignId must correspond to the journal's campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing location
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates the destructive nature of the operation but does not mention whether deletion is permanent, whether it cascades to related data, what happens if the location does not exist, or whether any permissions are required.
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 a single, front-loaded sentence with no redundant words. Every word earns its place for a simple CRUD deletion tool.
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?
Although the tool is simple, the description omits important context: return behavior, error cases, side effects, and the relationship between the two required parameters. With no output schema and no annotations, an agent cannot fully predict the outcome of invoking this 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 compensate for the two undocumented parameters. It provides no explanation of what 'id' and 'campaignId' represent, how they relate to the deletion, or which is the location identifier. The description adds no meaning beyond the raw schema property names.
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 clear verb ('Delete') and a specific resource ('existing location'), which states the operation unambiguously. It distinguishes the tool from its siblings (create, update, get, list) even though it follows the same pattern as other delete_* tools.
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 guidance is given about when to use this tool versus alternatives such as update_location or delete_character. The description simply states the action with no context, exclusions, or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing map
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the destructive action but does not mention whether deletion is permanent, reversible, or has cascading effects on associated data. This lack of detail is a significant gap for a delete operation.
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 extremely concise with no wasted words. However, it is too sparse to fully serve its purpose, so while compactness is praiseworthy, the extreme brevity slightly reduces the score.
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 destructive operation with no annotations and no output schema, the description is under-specified. It fails to convey parameter semantics, side effects, or any cautionary context. An agent calling this tool would have little idea what consequences to expect beyond 'deleting a map'.
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%, and the description 'Delete an existing map' explains nothing about the required parameters 'id' and 'campaignId'. The agent is left to guess which identifier targets the map and what the campaignId is used for, so the description adds no value beyond the raw schema.
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 ('Delete') and resource ('map'), clearly distinguishing this from sibling tools like create_map, update_map, and get_map. It also notes the map must already exist ('existing'), which adds useful 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 guidance is provided on when to use this tool versus alternatives, or any prerequisites such as the map needing to exist or be deletable. The intended usage is only implied by the verb 'Delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing note
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete an existing note' conveys that this is destructive, but it does not state whether deletion is permanent, what happens if the note does not exist, or any side effects.
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 a single short sentence with no filler or repetition. The core message is front-loaded and easy to parse.
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 tool with no annotations, no output schema, and zero parameter documentation, this description is too thin. It leaves parameter semantics, deletion behavior, and return value unspecified, making it only minimally usable.
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%, and the description adds no meaning for the two required parameters. The role of campaignId is entirely unexplained, and the description does not clarify how id and campaignId relate to the deletion operation.
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 the specific verb 'Delete' with the resource 'note', making the tool's action and target unambiguous. It is clearly distinct from sibling tools like create_note, update_note, get_note, and list_notes.
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 this tool is for deleting an existing note, but it gives no explicit guidance on when to choose it over alternatives or any exclusions. There is no mention of prerequisites, such as needing both the note id and campaignId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing organization
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete' which implies destructive action, but it does not disclose irreversibility, cascading effects, permissions required, or consequences for related data.
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 extremely concise and front-loaded, with no unnecessary words. However, it is under-specified: conciseness comes at the expense of essential context about parameters and behavior.
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?
The tool is simple, with only two parameters and no output schema, but the description is too sparse to be complete. The role of campaignId is completely unexplained, and no behavioral or safety context is provided, making this insufficient for confident 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 0%, and the description provides no explanation of the two required parameters, id and campaignId. The agent is left without any understanding of what these parameters represent or how they relate, which is a critical gap.
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 clearly states the action ('Delete') and the resource ('an existing organization'), making the core purpose immediately understandable. It does not explicitly differentiate from sibling delete tools, but the resource name itself provides sufficient 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?
No guidance is given about when to use this tool versus alternatives, such as update_organization or get_organization. There is no mention of prerequisites, contexts, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing quest
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, likely irreversible action, but the description does not state this, mention any cascading effects, permission requirements, or what happens when the quest is not found. This is a significant gap for a mutation 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 one short sentence with no filler or redundant phrases. It is appropriately front-loaded with the action and resource. However, it is almost too sparse, since it sacrifices useful parameter context for brevity.
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 tool with two required parameters, zero schema description coverage, no output schema, and no annotations, the description is not complete enough. It establishes the operation but fails to clarify the role of campaignId versus id, the destructive nature of the action, or any expected return behavior. An agent would need additional context to call this tool 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 0%, and the description provides no information about what 'id' or 'campaignId' mean, how they relate, or which one identifies the quest. The agent is left with only the raw schema, which gives types and required status but no semantic meaning. The description adds no value beyond the schema.
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 ('Delete') and a clear resource ('a quest'), making the operation unmistakable. It also implies the target must already exist, which distinguishes it from create_quest. Among the siblings, the verbs cleanly separate delete_quest from get_quest, update_quest, create_quest, and list_quests.
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 guidance about when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or conditions such as 'use delete_quest only when the quest exists' or 'use update_quest to modify instead.' The agent must infer usage entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing race
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations providing safety context, so the description carries the full burden. 'Delete an existing race' indicates a destructive action, but it does not disclose irreversibility, cascading effects, required permissions, or what happens after deletion.
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 a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though the brevity comes at the cost of missing behavioral and parameter details captured in other dimensions.
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 destructive operation with no annotations and no output schema, the description is too thin. It fails to explain the role of campaignId, whether deletion is permanent, or any constraints or side effects. An agent would need to infer critical context from the tool name and sibling tools.
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%, and the description does not explain either parameter. While 'id' and 'campaignId' are somewhat self-explanatory from their names, the description adds no meaning about which race is being deleted or why campaignId is required.
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 ('Delete') and a specific resource ('race'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like get_race, create_race, update_race, and list_races without requiring additional context.
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 guidance is given about when to use this tool versus alternatives such as update_race or get_race. The usage is only implied by the verb 'delete' and the tool name; there is no mention of prerequisites, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing timeline
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' signals a destructive operation, but it does not mention permanence, whether deletion cascades to related data, what happens if the timeline does not exist, or any required permissions. This is a significant transparency gap for a mutation 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 a single concise sentence with no fluff or repetition. It is front-loaded with the core action and target resource, so it is easy to parse quickly.
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 delete operation, the description is minimally viable but leaves gaps. It does not explain the relationship between campaignId and id, define success/failure behavior, or mention whether the delete is reversible. Without annotations or an output schema, more context would help.
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%, and the description adds no meaning to the parameters. It does not explain that 'id' is the timeline identifier or that 'campaignId' scopes the deletion to a campaign. The agent must rely entirely on property names.
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 ('Delete') and resource ('existing timeline'), so an agent can tell it deletes timelines rather than creating or updating them. However, it offers no detail that distinguishes it from the many sibling delete_* tools beyond the resource name.
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 guidance on when to use this tool versus alternatives such as delete_character or delete_event. The intended use is only implied by the resource name, and no exclusions, prerequisites, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a ability
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. 'Get details' implies a read operation, but the description does not mention response contents, campaign scoping, side effects, or error behavior.
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 short with no filler and leads with the main verb, but it is so sparse that it borders on under-specification rather than effective concision. There is no structural separation or additional useful context.
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 tool with no output schema, no annotations, and 0% parameter coverage, the description is insufficiently complete. It does not explain what details are returned, why campaignId is required, or how this tool relates to sibling lookup tools.
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%, and the description adds no meaning to either parameter. The agent is not told that campaignId is likely a scoping identifier and id is the ability identifier, nor what value shape or constraints apply.
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 ('Get') and resource ('ability') and implies fetching details for one ability, which is distinguishable from list_abilities and create/update/delete siblings. However, it does not explicitly explain how it differs from other get_* tools beyond the resource name.
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 guidance on when to use this tool or when to prefer alternatives such as list_abilities or search. The description gives no context like 'use this after obtaining an ability ID' or 'use list_abilities to find IDs first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a calendar
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details of a calendar' and gives no information about read-only guarantees, not-found behavior, permissions, or response shape. The verb 'Get' weakly implies a read operation, but that is not sufficient for full transparency.
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 brief, front-loaded, and free of filler. However, it is so minimal that it sacrifices informative content, making it under-specified rather than effectively concise.
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 two required parameters, no annotations, and no output schema, the description should explain how campaignId and id relate to retrieving a calendar. It does not mention the returned data, error cases, or usage context, leaving a significant completeness gap.
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%, and the description adds no explanation of what campaignId or id mean. 'id' can be guessed as the calendar identifier from context, but campaignId's role is completely unexplained, leaving a factual gap in how to call the tool correctly.
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 ('Get') and a specific resource ('calendar'), which is enough to distinguish it from list_calendars and create/update/delete_calendar siblings. However, it does not specify what 'details' includes, so it is clear but not maximally precise.
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 guidance about when to use get_calendar versus list_calendars or other get_* tools. The agent must infer usage from the tool name and schema rather than being told the appropriate context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a character
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. The verb 'Get' implies a read-only operation, and the description is consistent with that, but it adds no additional behavioral context such as error conditions, permission requirements, or response nature. For a simple read tool this is adequate but minimal.
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 a single short sentence with no filler or redundant phrases. It is front-loaded with the key information ('Get details of a character') and every word contributes to its meaning. Conciseness is excellent for a simple tool.
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 tool with two required parameters, no output schema, and no annotations, the description is too sparse. It does not explain parameter semantics, what the return value looks like, or how it differs in use from list_characters. An agent would need to infer critical details about how to call this 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 description coverage is 0%, so the description should compensate by explaining what 'id' and 'campaignId' mean. It only mentions 'character', which hints that 'id' is the character ID, but 'campaignId' is left completely unexplained. The description does not add enough meaning beyond the parameter names.
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 'Get details of a character' uses a specific verb ('Get') and identifies the resource ('character'), clearly distinguishing it from sibling tools like get_quest or get_location. It is unambiguous and not a tautology, though it doesn't elaborate on what 'details' includes, which prevents a top score.
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 provides no guidance on when to use this tool versus alternatives such as list_characters or search. It does not state that this tool should be used when a specific character ID is already known, nor does it mention any exclusions or prerequisites. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a creature
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states 'Get details of a creature' and gives no information about authentication requirements, not-found behavior, permissions, or whether campaignId scoping affects results.
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 extremely short and contains no fluff, but it is under-specified rather than appropriately concise. A single clause for a tool with two required parameters and no output schema leaves important information out.
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?
This is a simple retrieval tool, but with no annotations, no output schema, and a bare description, there is no explanation of what 'details' includes or what the response looks like. The description is not complete enough for an agent to know what to expect or how to handle edge cases.
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 the two parameters, but it does not mention id or campaignId at all. While the parameter names are somewhat self-explanatory, the description adds no information about their relationship, requiredness, or expected format beyond what the schema already shows.
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 ('Get') and resource ('creature'), clearly identifying the operation and distinguishing it from sibling tools like get_quest or get_item. However, 'details' is vague and does not specify what fields or scope are included.
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 provides no guidance on when to use this tool versus alternatives such as list_creatures or search. It is implied that this tool retrieves a single creature by ID, but no explicit context, prerequisites, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a event
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get details.' It does not state that the operation is read-only, whether authorization or campaign context is required, what response format to expect, or any side-effect profile.
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 brief but under-specified. 'Get details of a event' has a grammar error and provides no useful structure or distinguishing information; it is not appropriately sized for a tool with two required parameters and many siblings.
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?
The tool has no output schema, no annotations, two required parameters, and numerous sibling tools, yet the description offers only a near-tautology. There is not enough contextual information for an agent to reliably select and invoke this tool 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 description coverage is 0%, and the description does not mention or explain the two required parameters, id and campaignId. While the parameter names are somewhat self-explanatory, the description fails to compensate for the complete lack of schema descriptions.
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 'Get details of a event' is essentially a tautology of the tool name get_event. It adds only the word 'details' and does not specify what is included, how it is scoped, or how it differs from other get_* sibling tools.
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 guidance about when to use get_event versus list_events or any other sibling tool. No alternatives, exclusions, or usage conditions are mentioned, so an agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a family
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get details' implies a read-only retrieval, but it discloses nothing about the return payload, required scoping by campaign, or error/authorization behavior, leaving important behavioral context missing.
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 a single short sentence with no filler, but it is too under-specified to be considered appropriately sized. It conveys the basic action without any informative context, landing between efficient and merely skeletal.
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 getter with no output schema, no annotations, and no parameter documentation, the description is incomplete. An agent can guess that it retrieves a family, but not what data will come back or how the two required identifiers are meant to be used.
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%, and the description does not explain either parameter. The names 'id' and 'campaignId' are suggestive, but the description does not clarify that id likely refers to the family ID or why campaignId is required, so it fails to compensate for the missing schema documentation.
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 clear verb-resource pair ('Get details of a family'), so an agent can tell this is a read operation for a single family. It is somewhat generic and does not explicitly differentiate it from other get_* siblings beyond the resource name, so it falls 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?
No guidance is given about when to call get_family instead of list_families, search, or other get_* tools. The intended use is only weakly implied by the verb and resource, with no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a item
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden, but it only says 'Get details'. It does not disclose expected response shape, error behavior (e.g., not found), authentication needs, or side effects, though 'Get' does imply a read-only operation.
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 very short and front-loaded, with no fluff. However, it is under-specified and contains a grammatical error ('a item'), so it is not a well-crafted concise description that earns its place through substance.
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 the two required parameters, no output schema, and no annotations, the description is too minimal to be complete. It does not mention why campaignId is needed, what 'details' includes, or any behavior around missing or invalid identifiers, so an agent cannot reliably invoke it with full confidence.
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% and the description adds no meaning to the parameters. The required campaignId and id are both undocumented, and the description does not explain their relationship or how they should be used to fetch the item.
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 clear verb ('Get') and resource ('item'), so an agent can infer this is a read operation for a single item. It is not a tautology and is distinguishable from siblings like list_items and get_character by naming the item resource. However, it does not explicitly differentiate itself from similar get_* tools or clarify scope beyond 'details'.
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 gives no guidance on when to use this tool versus list_items, search, or other retrieval tools. There is no mention of prerequisites, campaign context, or exclusions, leaving the agent to guess when get_item is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a journal
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden, but it only restates that the tool retrieves details. It does not clarify read-only behavior, response contents, error behavior, or campaign scoping beyond the word 'Get'.
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 six-word description has no redundancy and is easy to scan. However, it is under-specified relative to the missing parameter and context information, so the brevity comes at the cost of usefulness.
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 two required parameters, no schema-level parameter descriptions, no output schema, and no annotations, this description leaves too much implicit. An agent cannot reliably determine what the parameters mean, what the returned details look like, or when this tool is preferable to the list/search variants.
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%, and the description does not explain either required parameter. The word 'journal' gives minimal context for interpreting 'id', but 'campaignId' and the relationship between the two IDs are left completely unexplained.
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 action ('Get details') and resource ('a journal'), which clearly identifies this as the singular retrieval tool for journals. It does not explicitly contrast with siblings like list_journals, but the singular phrasing and 'details' make the purpose unambiguous.
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 guidance about when to use this tool versus list_journals, search, or the other journal CRUD operations. It also does not state prerequisites like needing an existing journal id and campaignId, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a location
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet 'Get details of a location' adds nothing beyond the read-only implication already in the name. It doesn't state behavior for unknown IDs, whether campaignId scopes access, or what the response contains. There is no annotation contradiction, but also no behavioral context beyond the verb itself.
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 five-word sentence with no filler, front-loaded with the verb and resource. The structure is clean and scannable, though the brevity borders on under-specification — concision is achieved by omitting content rather than distilling it, which is why it doesn't earn a 5.
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 tool with 2 required parameters (one non-obvious: campaignId), zero schema parameter descriptions, no output schema, and no annotations, a five-word description is incomplete. The response format, the role of campaignId, and the difference from list_locations are all left to inference; the sibling list hints at a uniform CRUD pattern but the description never confirms it.
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, but it names neither parameter. The phrasing 'of a location' weakly implies id is the location identifier, which is already obvious from the tool name, while the required campaignId parameter remains completely unexplained — an agent cannot tell whether it is a scoping key, a tenant identifier, or an authorization token.
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 ('Get') and names the resource ('location'), so the core action is clear and it can be distinguished from get_quest/get_character by resource name. However, it doesn't explicitly differentiate from list_locations or clarify what 'details' means versus list output; an agent must rely on the get_/list_ naming convention to infer single-entity retrieval.
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 guidance is provided on when to use get_location versus list_locations, search, or the adjacent get_X tools. There are no stated prerequisites, exclusions, or alternative routing conditions — the agent must infer the call context entirely from the sibling list and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a map
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
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 only restates that the tool gets map details and adds no information about return shape, read-only behavior, pagination, or error conditions. This is minimally transparent beyond the operation name.
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 short and front-loaded, but it does not earn its place because it adds no information beyond the tool name. It is under-specified rather than appropriately concise.
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 get tool with two required parameters and no output schema, the description is incomplete. It does not clarify the role of campaignId, how to supply the IDs, or what kind of details will be returned, leaving important context to guesswork.
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%, and the description does not explain the meaning of id or campaignId. The agent is left to infer that id refers to the map and campaignId to the campaign, which is not stated anywhere.
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 'Get details of a map' clearly states a specific verb and resource. It does not explicitly differentiate this tool from sibling get_* tools, but the target resource is unambiguous.
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 guidance is provided about when to use this tool versus list_maps or other get_* tools. The description only implies that it is used when map details are desired, but offers no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a note
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of indicating behavior. 'Get details' clearly implies a read-only retrieval, but the description says nothing about response format, error behavior, or whether authentication/scoping beyond campaignId is needed.
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 a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple getter tool.
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 getter, the definition is minimally adequate: an agent can identify the action and required inputs. However, the absence of an output schema, annotations, and any parameter description leaves some ambiguity around the exact return value and ID semantics.
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%, and the description does not explain either parameter. Although 'id' and 'campaignId' are somewhat self-explanatory from their names, the description fails to state the relationship between them or what values are expected, which is a gap at this coverage level.
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 ('Get') and resource ('note'), making the core purpose clear. It also implicitly distinguishes itself from list_notes and search, though it doesn't explicitly state what 'details' includes.
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 gives no guidance on when to use this tool versus alternatives like list_notes or search. There are no stated conditions, exclusions, or references to sibling tools, so an agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a organization
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get details', which implies a read operation, but it does not disclose what happens on missing resources, whether any authentication or campaign scoping is required, or what the response contains.
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 a single short sentence with no filler and is easy to parse. It is appropriately concise, though the minor grammatical error and lack of detail slightly reduce clarity.
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 the absence of annotations and an output schema, the description is incomplete: it does not explain required parameter semantics, the meaning of 'details', or the shape of the returned object. An agent would have to infer most of the calling contract from the parameter names and tool name.
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 has 0% description coverage and the description adds no meaning for the two required parameters, campaignId and id. The parameter names are somewhat self-explanatory, but the description does not clarify that id identifies the organization or how campaignId scopes the lookup.
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 clear verb and resource: 'Get details of a organization'. The singular 'a organization' helps distinguish it from list_organisations and from create/update/delete variants, though it does not explicitly mention that retrieval is by ID or campaign-scoped.
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 guidance is given about when to use this tool versus alternatives like list_organisations or get_quest. The intended context is only implied by the 'get' verb and the resource name, with no explicit exclusions or routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a quest
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. 'Get details' clearly indicates a read/retrieval operation rather than a mutation, but it does not mention error behavior, authentication needs, or what the returned details actually contain.
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 a single efficient sentence with no redundant wording. It is front-loaded with the action and object, though the minimal length means some useful information is missing.
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 retrieval tool with two numeric required parameters and no output schema, the description is minimally usable. However, it omits the relationship between campaignId and id and provides no info on response shape or edge cases, leaving room for ambiguity.
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%, and the description adds no explanation of the two required parameters. The names id and campaignId are somewhat self-explanatory, but the description does not clarify how campaignId scopes or relates to the quest 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 uses a specific verb ('Get') and resource ('quest'), and the sibling list_quests makes it clear this is the singular retrieval tool. It is not tautological, though it lacks any scope or detail about what 'details' includes.
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 guidance is given about when to use get_quest versus list_quests or other alternatives. The sibling tools imply a distinction, but the description itself provides no context, exclusions, or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a race
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only implies a read operation via 'Get'. It does not mention whether the returned data is a full object, how to handle missing races, or any auth/scoping constraints, so the agent is left without behavioral context.
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 single sentence is concise and front-loaded, but it is under-specified rather than economically informative. It lacks parameter details and context, so the brevity comes at the cost of usefulness.
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 there is no output schema and no annotations, the description is incomplete: it does not explain what details are returned, how the two required parameters work, or how this tool relates to the other get_*/list_* siblings.
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% and the description mentions neither 'campaignId' nor 'id', so parameters are completely unexplained. An agent cannot infer that 'id' is the race ID and 'campaignId' scopes the request to a campaign.
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 clear action ('Get') and resource ('a race'), and the tool name confirms the entity type, distinguishing it from sibling get_* tools by resource. However, it does not specify that the race is scoped to a campaign or what 'details' includes, so it stops short of full clarity.
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 provides no guidance on when to use this tool instead of list_races, search, or other get_* tools. There are no exclusions or alternative routing, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a timeline
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details,' which implies a non-mutating read but does not disclose return format, pagination, error behavior, permissions, or side effects.
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 short and free of fluff, but it is also under-specified and largely restates the tool name. It is concise without being substantive, so it earns a middle score.
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 tool with no annotations, no output schema, and zero parameter documentation, a one-line generic description is not enough. The agent lacks critical information about required parameters, intended use, and expected behavior.
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%, and the description adds no meaning for 'id' or 'campaignId.' An agent is left to guess which id this is and what role campaignId plays, so the description completely fails to compensate for the schema gap.
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 ('Get') and resource ('timeline'), so an agent can tell this is the individual-read counterpart to list_timelines. However, it does not explicitly differentiate itself from sibling get_* tools or mention that a campaignId is required, so it stops short of full clarity.
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 guidance about when to use get_timeline versus list_timelines, search, or other get_* tools. The intended usage is only implied by the tool name and generic description, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List abilities
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'List abilities' is tautological. It does not state that this is a read-only operation, that results are scoped by campaign, that pagination is available via page, or what the response shape will be.
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 extremely short, but it simply restates the tool name and provides no useful elaboration. This is under-specification, not effective conciseness.
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?
The tool is simple, but the description is still inadequate. It omits the meaning of the required campaignId parameter, the pagination behavior, and any distinction from the many sibling list_* tools. An agent cannot reliably invoke this tool correctly based on the description alone.
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%, and the description adds no meaning to the parameters. The agent is left to guess the semantic role of campaignId and page, despite campaignId being required.
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 clear verb and resource: 'List abilities.' This distinguishes it from get_ability, create_ability, update_ability, and delete_ability. However, it does not mention any scope or filter, such as campaign-specific listing, so it does not fully differentiate from the other list_* tools.
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 guidance is provided about when to use this tool versus alternatives like get_ability or other list_* tools. The required campaignId parameter is not described, so an agent cannot infer the intended usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List calendars
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'List calendars' and does not mention pagination via page, the campaign scoping, ordering, or what the response contains. The tool appears read-only, but the description gives no detail about its actual runtime behavior, which is a significant 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?
The description is only two words, which makes it extremely terse but not appropriately sized. It under-specifies the behavior needed for correct invocation. Conciseness should not come at the expense of necessary information, so this is under-specification rather than effective conciseness.
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 no annotations, the description must explain required context and return values, but it doesn't. An agent cannot know that campaignId is required to scope the listing or what the list returns. The description is far too minimal for even a simple list tool with a required parameter.
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 explaining the parameters, but it does not. It adds zero meaning about campaignId being a required filter or page being for pagination. The parameter names are self-explanatory, but the description contributes nothing beyond what the raw schema already shows.
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 clear verb ('List') and resource ('calendars'), so an agent knows what entity this tool concerns. It doesn't explicitly state that calendars are scoped to a campaign, but the name and resource are distinct enough from siblings like get_calendar or list_quests. It's not a tautology and communicates the core action accurately.
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 provides no guidance on when to use this tool versus alternatives such as get_calendar or the create/update/delete calendar variants. The required campaignId parameter implies it lists calendars within a campaign, but this is never stated. An agent must infer usage context from the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all campaigns
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. 'List all campaigns' indicates a read operation but says nothing about return format, pagination, ordering, or whether any filtering occurs. The word 'all' adds some scope information, but the behavior is minimally disclosed.
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 words with no wasted content and the key action is front-loaded. For a zero-parameter, straightforward listing tool, this is appropriately concise rather than under-specified.
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, no-argument list operation, the description is nearly complete enough for an agent to invoke it correctly. Minor gaps remain around return shape and potential pagination, but the lack of parameters and the clear scope keep these from being significant.
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 has zero parameters and the schema coverage is 100% vacuously. There is no parameter meaning for the description to add, so the baseline of 4 is appropriate. The description does not need to elaborate on parameters that do not exist.
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?
'List all campaigns' states a specific verb and resource, and the qualifier 'all' clarifies the scope. It is immediately distinguishable from the many sibling list_* tools by naming the exact resource. No ambiguity exists about what the tool does.
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 when the agent needs the full set of campaigns, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Since there is no get_campaign sibling, the intended use is fairly obvious, but the guidance is still only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List characters
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says "List characters" and does not describe that it returns a paginated list, requires campaignId, applies campaign filtering, or has any other behavioral caveats.
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 extremely short, which is concise, but it is under-specified rather than efficiently informative. It front-loads the core action but fails to include essential scoping or parameter context.
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 list operation with one required parameter and no output schema, the description should at least mention the required campaignId and pagination behavior. It is far too incomplete for an agent to invoke this tool 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 0%, and the description mentions neither of the two parameters. The required campaignId and optional page are completely unexplained, leaving the agent to infer their meaning from names alone.
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?
"List characters" states a clear verb and resource, and the sibling list_* tools all follow the same naming pattern. However, it does not mention that characters are scoped to a campaign, which the schema requires, and it does not explicitly differentiate itself from the other list tools.
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 guidance about when to use this tool versus alternatives like get_character or search. The description simply names the action without any context for routing an agent to the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List creatures
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It does not state whether the operation is read-only, whether it requires a campaign context, that results are paginated via the page parameter, or what the response shape is. The description adds no behavioral insight beyond the name itself.
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 short, but this is under-specification rather than conciseness. 'List creatures' adds no information beyond the tool name and does not front-load any useful detail. Every sentence should earn its place; this phrase does not.
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 two parameters and no annotations or output schema, the description must carry the contextual burden. It does not mention the required campaignId, pagination behavior, or the scope of creatures returned. An agent cannot reliably select or invoke this tool correctly based on the description alone.
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 neither the schema nor the description explains the parameters. The description does not clarify that campaignId likely scopes the listing or that page controls pagination. With two parameters completely undocumented, the description fails to compensate.
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 'List creatures' is a near-verbatim restatement of the tool name. It states a generic verb and resource but provides no scope, filtering criteria, or relationship to the required campaignId parameter. It does not distinguish list_creatures from the many sibling list_* tools beyond the resource name.
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 guidance is provided about when to use this tool versus get_creature, list_characters, or search. There is no mention of prerequisites, such as needing a campaignId, nor any context for when listing creatures is appropriate. The agent is left without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List events
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. Saying 'List events' only indicates a read operation; it does not disclose pagination behavior, campaign scoping, limits, ordering, or return 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?
At two words, the description is terse, but this is under-specification rather than effective conciseness. It omits essential context and front-loads nothing useful beyond the tool name.
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 list tool with two parameters, no output schema, and no annotations, the description is incomplete. It does not explain the required campaignId, the pagination option, or what an agent should expect from the response.
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%, and the description adds no meaning for the two parameters. The required campaignId and optional page are not explained or even mentioned, leaving the agent without semantic guidance beyond raw schema properties.
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 clear verb and resource, 'List events', which identifies the operation and distinguishes it from sibling tools like list_campaigns or get_event. However, it fails to mention that events are apparently scoped to a required campaignId, so the stated purpose is incomplete.
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 guidance is given for when to use this tool versus alternatives such as get_event or list_campaigns. There is no mention of when campaign filtering applies or when a different list tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List families
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List families' implies a read operation but says nothing about required campaign scoping, pagination, return format, or any side effects. The agent is left without critical behavioral context.
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 only two words long, which is too terse to be considered appropriately concise. It omits essential scoping and parameter context, making it under-specified rather than efficiently structured.
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 tool with two parameters, no annotations, and no output schema, this description is grossly incomplete. The agent cannot correctly infer that campaignId is required, what the page parameter does, or what kind of result to expect. This is inadequate for reliable tool 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 0%, and the description provides no parameter information whatsoever. The required campaignId and optional page parameters are entirely undocumented in the description, so the agent must rely solely on the raw schema with no added meaning or context.
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 ('List') and resource ('families'), making the primary action clear. However, it does not differentiate this tool from the many sibling list_* tools beyond the resource name, and it omits the campaign scoping implied by the required campaignId parameter.
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 guidance is given about when to use this tool versus alternatives such as get_family or other list_* tools. The description leaves the agent to infer that this tool is for fetching multiple families rather than a single one, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List items
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not mention that campaignId is required, how the page parameter behaves, whether the operation is read-only, or what counts as an 'item' in this domain.
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 short but under-specified rather than appropriately concise; it is essentially a tautology that saves words at the expense of all useful information. A meaningful description could still be brief while conveying scope and requirements.
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, no annotations, and a 0% parameter coverage, the description needed to carry the full context but provides none. An agent cannot know that campaignId is required, how paging works, or what resource is being listed, making correct invocation impossible from the description alone.
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 the undocumented parameters, but it adds nothing. It does not clarify that campaignId is required or that page likely controls pagination, leaving the schema's raw field names as the only guidance.
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 'List items' is a near-verbatim restatement of the tool name, providing no additional specificity about what 'items' refers to or the scope of listing. It does include a verb and resource, but it fails to distinguish this tool from the many sibling list_* tools (list_characters, list_quests, etc.).
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 guidance about when to use list_items versus get_item for retrieving a single item, or versus other list_* tools for different resource types. The description offers no context, prerequisites, or alternatives, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List journals
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the action and gives no information about required parameters, pagination behavior, return shape, or side effects.
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 under-specified rather than concise. While it is short, the sparse wording omits essential invocation details and earns no conciseness credit.
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 no annotations, the description should explain the required campaignId, pagination, and its relationship to journal CRUD siblings. It provides none of this, leaving the agent without enough context to call 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 description coverage is 0%, and the description mentions neither campaignId nor page. An agent must rely entirely on parameter names and types to infer their meaning and constraints, which is insufficient.
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 'List journals' is essentially a verbatim restatement of the tool name, adding no scope, filter, or distinguishing context. It communicates the basic action but does not clarify what subset of journals is returned or how it differs from other list_* siblings.
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 usage guidance is provided. The description does not mention that campaignId is required, how pagination works, or when to prefer list_journals over get_journal or other list_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List locations
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'List locations' offers none—no mention of read-only semantics, pagination, campaign scoping, or response format. It simply restates the operation name.
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 extremely short but under-specified rather than appropriately concise. It fails to include any useful information beyond the tool name, so it is not a case of efficient writing but of missing substance.
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 tool with a required campaignId parameter and no output schema, this description is severely incomplete. An agent cannot determine the campaign requirement, pagination behavior, or what constitutes a 'location' in this system, making the tool effectively unusable without external knowledge.
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% and the description does not mention campaignId or page at all. The agent is left to infer that campaignId is a filter key and page controls pagination, but nothing in the description helps clarify their meaning or usage.
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 'List locations' is a direct restatement of the tool name 'list_locations', converting underscores to spaces and capitalizing. It adds no new information about scope, entity filtering, or relation to sibling tools, making it a tautology rather than a clarifying statement.
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 guidance is provided about when to use this tool versus alternatives like get_location or other list_* tools. The description does not mention the required campaignId context or whether to prefer listing over getting a single location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List maps
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'List maps' implies a read-only operation but does not disclose pagination behavior, the requirement for campaignId, or the shape of the returned list. It does not contradict annotations because none exist.
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 extremely short and front-loaded, but this is under-specification rather than effective conciseness. Two words that restate the tool name add no value beyond the name itself.
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 tool with two parameters, one required, and no annotations or output schema, the description is far from complete. It omits the campaign-scoping requirement, possible pagination semantics, and any indication of the return format, all of which are needed 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 0%, and the description provides no explanation of either parameter. The required campaignId and optional page are completely undocumented, leaving an agent to guess their meaning from names and types.
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 'List maps' is a verb-plus-resource statement, but it merely restates the tool name with no added detail, making it a tautology. It does not specify the scope of maps (e.g., maps within a campaign) or explicitly differentiate itself from the sibling get_map, relying only on the plural form to imply a collection operation.
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 guidance on when to use this tool versus alternatives. It does not mention get_map or other list_* tools, nor does it indicate that campaignId is required to scope the listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description discloses no behavioral traits such as pagination, read-only semantics, ordering, limits, or dependency on campaignId. The agent gets nothing beyond the verb 'list'.
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 short but this is under-specification rather than efficient conciseness. It conveys no information beyond the tool name and does not earn its place as a helpful definition.
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 two parameters, a required campaignId, no annotations, no output schema, and many siblings, 'List notes' is far too incomplete. It omits essential context about filtering, return values, and relationship to get_note.
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%, and the description does not mention campaignId or page. The agent must guess the meaning of the required parameter from its name alone.
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 'List notes' is effectively a restatement of the tool name. It provides no detail about scope, filtering, or how this tool differs from the sibling get_note or other list_* tools.
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 guidance on when to use list_notes instead of get_note, or when the required campaignId should be provided. An agent cannot determine whether this lists all notes or notes scoped to a campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List organisations
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only indicates a list/read operation and does not disclose whether results are paginated, whether organizations are scoped to the required campaignId, what the response shape is, or any side effects.
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 short, but it is under-specification rather than effective conciseness. The single phrase merely repeats the tool name and offers no structured or decision-relevant content, so it does not earn its place.
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 annotations and no output schema, the description is not complete enough for reliable invocation. An agent cannot tell that organisations are campaign-scoped, what page controls, or what the response will contain; the schema names the parameters but the description adds no surrounding context.
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%, and the description mentions neither campaignId nor page. The only required parameter, campaignId, is not contextualized as the owning campaign, and the optional page parameter's paging semantics are completely 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?
The description 'List organisations' simply restates the tool name list_organisations without adding any scope, filtering, or campaign context. It is a tautology rather than a genuinely informative purpose statement, and it does not help differentiate the tool from sibling list/get tools beyond the bare resource name.
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 guidance on when to use this tool versus get_organization or the other list_* sibling tools. The description does not mention the required campaignId, explain pagination, or state any exclusion criteria, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List quests
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, but it only says 'List quests'. It does not state that the operation is read-only, that results are paginated via the page parameter, or that it is scoped to a campaign. The verb 'list' weakly implies read-only, but no meaningful behavioral context is given.
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 extremely short and free of waste, but this is under-specification, not conciseness. For a tool with two parameters and many siblings, a two-word description does not provide enough 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?
The tool requires campaignId and offers pagination, yet the description provides no context about return values, campaign scoping, or how this list behaves. With no output schema or annotations, the description is inadequate for an agent to invoke the tool 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 description coverage is 0%, so the description must explain the parameters, but it mentions neither campaignId (required) nor page (optional). An agent has no semantic understanding of what these parameters mean beyond their names.
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 'List quests' is a tautology: it merely restates the tool name 'list_quests' in natural language without adding any scope, filtering, or campaign context. It is not misleading, but it adds no clarifying information beyond what the name already conveys.
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 usage guidance is provided. The description does not indicate when to use this tool instead of get_quest, search, or list_campaigns, nor does it mention that a campaignId is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List races
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'List races' only implies a read-only operation and does not mention pagination, filtering behavior, required campaign context, or any other side effects or constraints.
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 extremely short and contains no wasted words, but it is under-specified rather than efficiently concise. A single phrase such as 'List races' does not earn its place because it simply restates the tool name and adds no useful behavioral or contextual 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?
For a tool with no annotations and no output schema, the description should explain the required campaignId parameter, the meaning of page, and what a successful response contains. None of that is present, so the description is not complete enough for an agent to invoke the tool with confidence.
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 explain the parameters, but it does not mention campaignId or page at all. The agent receives no additional meaning beyond what the bare schema property names and types already provide.
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 ('List') and resource ('races'), so the basic action and target are clear. It does not differentiate this tool from the many other sibling list_* tools beyond the resource name, but the resource name itself is sufficient given the sibling set.
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 guidance about when to use list_races versus alternatives such as get_race, search, or other list tools. The context signals and sibling names imply a list-versus-get pattern, but the description does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List timelines
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not mention pagination behavior, campaign scoping, permissions, or what response shape to expect.
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 words is under-specification, not effective conciseness. A useful description of a list operation with required and optional parameters should include more operational context.
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 annotations, no output schema, incomplete parameter documentation, and a broad sibling set, this description is far too thin. It does not explain what a timeline is, how campaignId filters results, or how page behaves.
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 by explaining the two parameters. It does not mention campaignId or page at all, leaving the agent to guess that campaignId is required and how pagination works.
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 'List timelines' is a tautology that simply restates the tool name. It names a verb and resource but adds no scope or differentiation from siblings like get_timeline or list_events.
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 guidance about when to use this tool versus alternatives such as get_timeline, create_timeline, or list_campaigns. An agent must infer the intended use entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search entities
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. 'Search entities' only implies a read operation; it does not state whether the search spans all entity types, how results are returned, whether pagination exists, or that campaignId scopes the search. It does not contradict any annotations, but it provides almost no behavioral context.
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 words is maximally terse, but this is under-specification rather than conciseness. The description functions as a stub and does not earn its place by conveying 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?
With two required parameters, no output schema, and no annotations, the description is grossly incomplete. It gives no indication of which entities are searchable, what the response looks like, how to interpret q, or any search behavior such as pagination or campaign scoping.
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%, and the description does not mention q or campaignId at all. It adds no meaning beyond the bare schema types, leaving the agent to guess what q means, how search matching works, and why campaignId is required.
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 clear verb ('Search') and a resource ('entities'), but 'entities' is undefined and could mean any or all of the many entity types present in the sibling tools. It is not a tautology, but it lacks the specificity needed to distinguish the exact scope of the search.
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 guidance on when to use this tool rather than list_campaigns, list_characters, or one of the other list tools. No conditions, exclusions, or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing ability
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it reveals nothing beyond the bare implication of mutation. It does not state whether the data object is a partial patch or full replacement, whether the operation is reversible, what permissions are required, or what side effects updating an ability may have on dependent entities.
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 words with the verb front-loaded, so nothing is wasted. But the text is under-specified rather than efficiently complete — it omits the parameter and behavioral context that this tool's complexity requires, making this brevity a limitation rather than a strength.
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 mutation tool with 3 required parameters, an opaque nested data object, no annotations, and no output schema, this description is entirely inadequate. An agent cannot determine required field structure, update semantics, or expected response, making correct invocation unlikely without external knowledge.
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%, and the description provides no compensation: it never mentions id, campaignId, or the shape of the data object. Since data is an unconstrained nested object with no documented properties, an agent has no way to construct a valid payload from either the schema or the description.
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 ('Update') and resource ('ability'), making the core operation clear within the CRUD family of sibling tools such as create_ability, get_ability, and delete_ability. However, it is essentially the tool name expanded into a sentence and adds no detail about what aspects of an ability can be updated, so it stops short of the specificity needed for 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?
The description gives no guidance on when to use this tool versus create_ability or delete_ability, no prerequisites, and no exclusions. An agent receives no help choosing among the mutation variants in the ability family or understanding the conditions under which an update is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing calendar
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It only states that the operation updates an existing calendar, revealing minimal information about side effects, partial vs. full updates, required permissions, or the response. This is a significant gap for a data-modifying operation with no support from 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?
At six words, the description is short but this is under-specification rather than conciseness. It contains no wasted words but also no meaningful content beyond what the tool's name already states. A well-structured description would front-load the purpose and then elaborate on parameters or behavior.
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 mutating tool with three required parameters, one of which is a nested object, and no annotations or output schema, the description is grossly incomplete. An agent cannot determine what to pass in data, what id refers to, or what the update will affect. This falls far short of what is needed 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 0%, so the description must compensate by explaining the parameters. It names none of the three required parameters (campaignId, id, data) and gives no hints about their roles. The nested data object is entirely undocumented, leaving an agent with no semantic information beyond the raw schema.
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 ('Update') and a clear resource ('calendar'), and the qualifier 'existing' distinguishes the operation from creation. This clearly identifies the tool's core function within the CRUD family of sibling tools. However, it lacks detail on what aspects of the calendar can be updated, which prevents a perfect score.
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 explicit usage guidance is provided. The description implies the tool is for modifying an existing calendar, but it does not state when to choose this over create_calendar or delete_calendar, nor any preconditions. The intended use case is inferable from the name and verb, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing character
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavior. 'Update an existing character' only implies mutation; it does not state whether the update is a partial patch or full replacement, what happens if the character ID does not exist, whether permissions are required, or any side effects. This is a significant gap for a write operation.
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 a single short sentence, but it is under-specified rather than concise. 'Update an existing character' largely restates the tool name and adds only the word 'existing'. It does not earn its place by providing useful information beyond the name.
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 three required parameters, one being a nested object, no output schema, and no annotations, this description is severely incomplete. There is no explanation of the nested structure of 'data', the necessity of 'campaignId', or the expected result. An agent cannot confidently invoke this tool 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 description coverage is 0% and the description adds no meaning to the parameters. It does not explain that 'data' contains the fields to update, what 'id' refers to, or the role of 'campaignId'. The agent is left without any understanding of how to populate the three required parameters.
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 ('Update') and resource ('existing character'), which identifies the operation clearly. It distinguishes itself from create_character and delete_character by the word 'existing', though it does not specify what fields or aspects of the character are updated.
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 guidance is given on when to use this tool versus alternatives like create_character, get_character, or delete_character. The usage context is only implied by the phrase 'existing character', but there is no explicit mention of prerequisites, target scenarios, or exclusion rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing creature
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description does not state whether the update is partial or full replacement, whether it requires ownership or special permissions, what happens to omitted fields, or what the response will contain.
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 phrase 'Update an existing creature' is so terse that it essentially restates the tool name with the word 'existing'. While it is front-loaded and free of fluff, this is under-specification rather than effective conciseness, since critical information is missing.
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 tool with three required parameters including a nested data object, no output schema, and no annotations, a one-sentence description is wholly inadequate. An agent has no information about required data shape, return values, failure modes, or behavioral semantics, making the description insufficient 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 0%, and the description does not explain any of the three required parameters. The 'data' object, 'id', and 'campaignId' are entirely undocumented, leaving an agent without any guidance on what values to supply or how the data object should be structured.
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 clear verb ('update') and resource ('creature'), and the word 'existing' helps distinguish it from create_creature and delete_creature. It is slightly generic because it does not indicate what aspects of the creature can be updated, but the purpose is unambiguous.
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 gives no guidance on when to use this tool versus alternatives like create_creature or get_creature. There is no mention of prerequisites, such as the creature needing to already exist, nor any exclusion criteria or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing event
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Update an existing event' without explaining whether the update is partial or full, whether it is reversible, what side effects occur, or whether permissions are needed. This is a significant transparency 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?
The description is extremely short, but brevity here stems from under-specification rather than efficient communication. It conveys only the most basic operation and omits all contextual and behavioral information an agent needs. A concise description should still add meaningful guidance.
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 annotations, no output schema, and a nested data parameter, the description is far from complete. An agent cannot reliably construct a correct update request for an event based on this description alone. It needs details about data object structure, required identifiers, and update behavior.
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%, and the description adds nothing about the three required parameters: campaignId, id, and data. The nested 'data' object is entirely unexplained, leaving the agent without guidance on its structure or required fields. The description fails to compensate for the schema's lack of documentation.
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 the specific verb and resource: 'Update an existing event.' This clearly distinguishes it from sibling tools like create_event, get_event, and delete_event. It lacks detail about what aspects of an event can be updated, but the core purpose is unambiguous.
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 guidance is given on when to use this tool versus alternatives. There are no mentions of prerequisites, required context, or exclusions. The use case is only implied by the tool name and the general CRUD pattern of the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing family
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Update' and does not clarify whether this is a partial update, what happens to omitted fields, whether it is idempotent, what errors occur if the family does not exist, or what the response contains.
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 compact and front-loaded, with no filler words. However, it is so terse that it under-specifies critical information, so the brevity is not fully earned.
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 three required parameters, one of which is an unspecified nested object, no output schema, and no annotations, this description is far too minimal. It should explain the role of each parameter, the expected shape of 'data', and the behavior of the update operation.
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%, and the description provides no explanation for campaignId, id, or data. The parameter names hint at IDs, but the 'data' object is completely opaque, leaving an agent unable to construct a valid update payload.
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 clearly states the action ('Update') and the resource ('existing family'), which helps distinguish it from create/delete/get family tools. However, it is largely a rephrasing of the tool name and gives no detail about what specific family attributes can be updated.
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 guidance on when to use this tool versus create_family, get_family, or other update_* tools. No prerequisites are stated, such as the family needing to exist first, and there is no indication of when an alternative should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing item
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral disclosure, but it only restates the operation. It does not mention what happens if the item does not exist, whether data is merged/replaced, required permissions, or what the response contains.
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 a single short sentence with no redundancy, so it is structurally clean. However, it is under-specified and not appropriately sized for a tool with three required parameters and no other documentation.
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 mutation tool with no annotations, no output schema, and a nested data parameter, the description is incomplete. An agent cannot know what to pass in the data object, what campaignId represents, or what side effects to expect.
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, but it mentions none of the three required parameters (campaignId, id, data). It adds no meaning beyond the raw schema field names.
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 ('Update') and resource ('existing item'), making the primary operation clear. It does not explicitly differentiate from sibling create/delete tools, but 'existing' provides a meaningful 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?
No guidance is provided about when to use this tool versus create_item, delete_item, or other update_* tools. The only implicit usage signal is 'existing' in the description, which is not actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing journal
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update', without indicating whether the update is partial or full replacement, what effects occur, whether permissions are needed, or what the response contains.
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 only four words and contains no wasted text, but it is severely under-specified for a tool with three required parameters and an undocumented nested object. This is under-specification rather than effective conciseness.
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?
There is no output schema, no parameter documentation, and no behavioral detail. The description says essentially nothing beyond the operation name, leaving an agent without enough context to construct a valid request or understand the tool's behavior.
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%, and the description mentions no parameters at all. An agent cannot determine what campaignId, id, or the nested data object mean, what shape data should take, or how the parameters relate to the update operation.
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 the verb 'update' and the resource 'journal', and says 'existing', which helps distinguish it from create_journal. However, it does not explain what kind of update or what fields are affected, so it only partially differentiates from the many sibling update_* tools.
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 guidance on when to use this tool versus alternatives such as get_journal or create_journal, and no mention of prerequisites like needing an existing journal ID. Usage context must be inferred entirely from the tool name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing location
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that an update occurs, but does not explain whether the update is partial or full, what happens to omitted fields, authentication requirements, or side effects.
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 extremely brief and front-loaded, but it is under-specified rather than appropriately concise. Given three undocumented parameters and a nested object, this length is not suitable for guiding correct invocation.
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?
The tool requires three parameters, has no output schema, and has no annotations. The description does not explain the data shape, the role of campaignId, or any update behavior, making it inadequate for an agent to use safely and 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 description coverage is 0%, and the description provides no meaning for campaignId, id, or the nested data object. The data property is completely opaque, leaving the agent without any understanding of what fields can or should be updated.
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 clearly states the verb 'Update' and the resource 'existing location', making the core operation unambiguous. It does not explicitly differentiate from sibling update_* tools, but the resource name in the tool name and description provides sufficient 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?
The description offers no guidance on when to use this tool versus alternatives such as create_location or delete_location. It implies the target already exists, but there is no explicit context, prerequisite, or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing map
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update' which implies mutation, but it does not disclose whether the operation is destructive, whether data replaces or merges fields, or what side effects or requirements exist. For a mutation tool this is a significant transparency 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?
The description is concise at one short sentence, but it is under-specified to the point of being uninformative. It essentially restates the tool name and provides no useful information, so the brevity does not contribute to clarity.
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 an update operation with three required parameters, one of which is an unstructured object, and no output schema or annotations, this description is wholly inadequate. It fails to explain the request shape, expected response, or any constraints, making correct invocation impossible without external knowledge.
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%, and the description provides no explanation of the parameters. The 'data' object is opaque, and the roles of campaignId and id are unexplained, leaving the agent without any indication of what values to provide.
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 'Update an existing map' is a clear verb+resource statement and it implies the map exists, distinguishing it from create_map. However, it adds almost no information beyond the tool name and doesn't describe what 'update' entails or differentiate from other update_* siblings, leaving the purpose functional but shallow.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention create_map, get_map, delete_map, or any conditions that would select this tool, so an agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing note
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates that the action is an update and that the note already exists. It does not mention partial vs. full update semantics, handling of missing ids, permissions, or response behavior.
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 short and has no padding, but it is under-specified rather than genuinely concise. A single four-word sentence is not enough substance for a tool with three required parameters and a nested object.
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?
The tool has three required parameters, a nested data object, no output schema, and no annotations; a one-sentence description is far from sufficient for reliable invocation. The description does not hint at the shape of 'data' or how 'campaignId' relates to the note.
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%, and the description adds no meaning to the three required parameters. The nested 'data' object is completely opaque, and the roles of 'id' and 'campaignId' are not explained, leaving the agent unable to construct a valid payload.
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 clear operation ('Update') and resource ('existing note'), so an agent can distinguish it from create_note, delete_note, get_note, and list_notes. However, it does not specify which fields can be updated, so it is only minimally precise.
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 the tool is for modifying an already-created note, but it gives no explicit guidance on when to use it versus create_note, whether the note should be fetched first, or what constraints apply. No alternatives 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.
Update an existing organization
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It gives no indication of whether this is a partial or full update, what happens to omitted fields, whether permissions are needed, or what the response contains.
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 short, but it is under-specified rather than appropriately concise. It merely restates the tool's purpose and provides no structural guidance about parameters or usage.
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 three required parameters, a nested data object, no output schema, and no annotations, this tool needs substantial explanatory context. The description supplies none of it, making the tool almost entirely opaque to an agent.
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%, and the description does not explain any of the three parameters. 'data' is an untyped object, and 'campaignId' and 'id' are unexplained, leaving the agent to guess their roles and formats.
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 clearly names the action (update) and the resource (organization), and 'existing' signals this is not a create operation. However, it does not differentiate this tool from the many sibling update_* tools beyond the resource type.
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 guidance about when to use this tool versus create_organization, delete_organization, or get_organization. The intended usage is only implied by the tool name and the word 'existing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing quest
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden, but it only says 'update an existing quest'. It does not specify whether this is a partial update or full replacement, what happens for invalid ids, whether campaignId must match, or what response an agent can expect.
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 short and starts with the verb, but at only four words it is under-specified for a tool with three required parameters and a nested object. It is concise in length but not in a way that serves the agent's needs.
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 mutation tool with all-required parameters, a nested 'data' object, no output schema, and no annotations, the description is far too thin to allow correct invocation. Missing details include accepted data fields, return behavior, error handling, and the relationship between campaignId and id.
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% and the description explains none of the three required parameters. The 'data' object has no documented fields, and the roles of 'id' and 'campaignId' are entirely undefined, so an agent cannot determine what to supply.
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 clearly states the verb ('update') and resource ('quest'), and the word 'existing' indicates it operates on an already-created quest rather than creating a new one. This distinguishes it from create_quest, list_quests, and delete_quest, though it adds little beyond what the tool name already communicates.
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 guidance on when to use this tool instead of alternatives like create_quest or get_quest. No prerequisites, conditions, or exclusions are mentioned; the only hint is the word 'existing', which is already implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing race
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates mutation but doesn't clarify whether the update is partial or full replacement, whether permissions are needed, or what happens to fields not included in 'data'. This is too sparse for a write operation.
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 one-sentence description is efficient and front-loaded with the verb, with no wasted words. However, it sacrifices necessary substance for brevity, making it under-specified for a tool with three required parameters.
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 mutation tool with three required parameters, no annotations, and no output schema, this description is severely incomplete. It omits any explanation of the data payload, campaign scoping, or update behavior, leaving an agent unable to safely construct a valid request.
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%, yet the description names none of the three parameters. 'data' is an untyped object in the schema and remains completely unexplained in the description, and the meaning of 'id' and 'campaignId' is also unaddressed. The description adds zero value beyond the schema.
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 clear verb ('Update') and resource ('existing race'), which distinguishes it from sibling tools like create_race, delete_race, and get_race. It is unambiguous enough for an agent to know the core operation, though it doesn't mention updatable fields.
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 guidance on when to use this tool versus create_race or delete_race, no prerequisites such as fetching the race first, and no mention of campaign scoping. An agent must infer from the schema that an existing ID is required, but there is no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing timeline
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| campaignId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure, yet it only restates what the name already implies: that the operation mutates an existing timeline. It does not disclose whether data is a partial patch or full replacement, how nonexistent IDs are handled, permission requirements, or idempotency.
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 only four words with no wasted verbiage, but this brevity is under-specification rather than deliberate conciseness — it essentially restates the tool name and front-loads nothing of substance.
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?
This is a mutation tool with three required parameters including a fully opaque nested data object, zero annotations, and no output schema. The description provides no payload shape, no call semantics, and no behavioral context, which is wholly inadequate for reliable 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 0%, and the description does nothing to compensate. It never clarifies that id is the timeline identifier, what campaignId refers to, or what shape the required data object must take. An agent cannot construct a valid invocation from the available information.
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 ('Update') and resource ('timeline'), and the qualifier 'existing' minimally distinguishes the operation from creation. However, it adds nothing beyond the tool's name pattern, which is identical across dozens of sibling update_* tools, so an agent learns no specifics about what updating a timeline entails.
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 provides no guidance on when to use this tool versus create_timeline, delete_timeline, or get_timeline, nor any prerequisites such as needing the timeline ID and campaign context. Tool selection is left entirely to inference from the sibling tool names.
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.
v2.1.1create_abilitycreate_calendarcreate_charactercreate_creaturecreate_eventcreate_familycreate_itemcreate_journalcreate_locationcreate_mapcreate_notecreate_organizationcreate_questcreate_racecreate_timelinedelete_abilitydelete_calendardelete_characterdelete_creaturedelete_eventdelete_familydelete_itemdelete_journaldelete_locationdelete_mapdelete_notedelete_organizationdelete_questdelete_racedelete_timelineget_abilityget_calendarget_characterget_creatureget_eventget_familyget_itemget_journalget_locationget_mapget_noteget_organizationget_questget_raceget_timelinelist_abilitieslist_calendarslist_campaignslist_characterslist_creatureslist_eventslist_familieslist_itemslist_journalslist_locationslist_mapslist_noteslist_organisationslist_questslist_raceslist_timelinessearchupdate_abilityupdate_calendarupdate_characterupdate_creatureupdate_eventupdate_familyupdate_itemupdate_journalupdate_locationupdate_mapupdate_noteupdate_organizationupdate_questupdate_raceupdate_timelineScored across 77 tools
Each entity type has a clear list/get/create/update/delete set, so tools are mostly distinguishable by resource and action. The main confusion points are the organisations/organization spelling mismatch and campaigns having only list_campaigns, but there is no genuine functional overlap.
Tool names follow a consistent list_plural/get_singular/create_singular/update_singular/delete_singular snake_case pattern across nearly all entities. Minor deviations like `list_organisations` vs `get_organization` and the bare `search` prevent a perfect score.
77 tools is far beyond the typical well-scoped MCP surface and will impose a heavy context burden on agents. While the repetition is systematic, covering 15 entity types with full CRUD creates excessive bloat for what is ultimately a single domain.
The server covers full CRUD for most major Kanka entity types, which is strong domain coverage. The notable gap is campaigns: only list_campaigns exists, with no get/create/update/delete, and some secondary Kanka features like tags or relations are absent.
Manage your tabletop RPG campaign from any MCP client: worlds, sessions, quests, lore, recaps.
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
Rick and Morty MCP — wraps the Rick and Morty API (free, no auth)
Manage Kajabi from any MCP client — products, pages, contacts, offers, emails, analytics.
