spirrow-prismind

Official

by SpirrowGames

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Most tools target distinct resources/actions, but there is overlap between start_task/complete_task/block_task and update_task_status, as well as between check_services_status and get_connection_info, which could cause misselection. Descriptions help clarify intent, but the boundaries are not always clean.
Naming Consistency5/5
All tools use snake_case with a clear verb_noun pattern (get_, list_, create_, update_, delete_, etc.). The verbs are consistent and predictable, with only minor special cases like 'configure' and 'upsert_identity'.
Tool Count2/5
With 46 tools, this is significantly more than typical and feels heavy. Many convenience wrappers (e.g., start_task, complete_task, block_task) could be folded into update_task_status, and several config/status tools could be consolidated.
Completeness5/5
The tool surface covers CRUD and lifecycle operations for sessions, projects, documents, knowledge, and tasks, plus configuration and identity management. No major gaps are apparent; the domain appears fully covered.
Average 3.5/5 across 46 of 46 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 merely says 'Search the document catalog' with no mention of return format, filtering behavior, pagination, or side effects, providing almost no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but under-specified, offering no structural value or useful detail. It states the obvious without earning its place as a valuable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five optional filters, no output schema, and no annotations, this description is completely inadequate. It lacks critical information about result handling, filter application, and tool behavior, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all five parameters, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the document catalog, providing a verb and resource. However, it does not distinguish this from sibling tools like search_knowledge or find_similar_document_type, making it less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 gives no context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Update a document.' It does not disclose that the tool can either replace or append content based on the 'append' parameter, nor does it mention potential destructive effects or response behavior. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, so it is concise. However, it is under-specified to the point of providing minimal utility. While it is front-loaded, the lack of content makes it less useful than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description is severely incomplete. It provides no context about how the update works, when to use it, what the parameters mean in combination, or what the response will be. The agent would have to rely entirely on the schema and external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description adds no additional meaning beyond the schema, which meets the baseline expectation but does not go further to explain parameter interplay or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a document' clearly states the verb and resource, but is very generic and does not specify what aspects can be updated or how. It does not distinguish the tool from other update-like tools in the sibling list, such as update_project or update_knowledge, 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.
Usage Guidelines2/5
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 create_document or delete_document. The description does not mention append mode, replacement behavior, or any preconditions, leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral traits. It only says 'create a new document and register it in the catalog' without detailing side effects, permissions, duplicate handling, or what 'register in the catalog' entails. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It efficiently states the core action and a key consequence ('registers it in the catalog').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description leaves out behavioral details such as return values, error conditions, and catalog-specific semantics. While the schema covers parameter meaning, the overall context is under-specified for a create operation with 7 parameters and no additional metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its 7 parameters, so the schema provides full parameter semantics. The description adds no extra information about parameters, but the baseline score of 3 applies because schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Create') and identifies the resource ('a new document'), plus an additional catalog registration detail. It is distinct from sibling tools like update_document and delete_document, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 update_document or add_knowledge. The description merely states the action, leaving the agent to infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the optional drive folder deletion but does not disclose that the action is destructive, permanent, or requires confirmation. This is a significant gap for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and is free of unnecessary words. It earns a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and minimal annotations, the description is incomplete. It does not explain whether the project itself is deleted, that confirm must be true for execution, or the irreversible nature of the drive folder deletion. The schema covers parameters but not the overarching consequences, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage), so the baseline for this dimension is 3. The description adds minimal extra meaning merely by mentioning the drive folder deletion option, which aligns with the delete_drive_folder parameter, but does not substantially enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as deleting project settings and optionally the associated Google Drive folder, which distinguishes it from sibling tools like delete_document or delete_session. However, 'delete project settings' is slightly ambiguous as to whether the entire project is deleted or just its settings, preventing 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.
Usage Guidelines2/5
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_project or other project management tools. It also fails to mention the required confirmation parameter or warn that deletion is irreversible, leaving the agent without context for safe invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state whether the tool is read-only, what the return format is, whether it can return multiple results, or any side effects. 'Search and retrieve' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. However, it is somewhat under-specified, so it's concise but not necessarily optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters, no output schema, and no annotations, the description is far too minimal. It does not explain what is returned, how to use the parameters effectively, or how this tool fits among many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify the relationship between 'query' and 'doc_id' or how filters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search and retrieve a document' clearly identifies the action (search/retrieve) and resource (document). However, it does not distinguish this tool from sibling tools like search_catalog or list_documents, which also involve finding/retrieving document-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 use cases, exclusions, or scenarios where another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only reveals the data source ('Google Sheets') and implies a read operation via 'Get', but does not disclose whether it is read-only, requires authentication, or how it handles missing projects or phases. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately conveys the core purpose, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 what the returned progress looks like or how it is structured, but it does not. It also omits any context on how progress relates to project phases or the Google Sheets integration, making it incomplete for a tool with no other structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters ('Phase filter' and 'Project ID'), so the description adds no additional meaning. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('get') and resource ('project progress') with a data source ('from Google Sheets'), distinguishing it from sibling tools like get_setup_status or list_projects. However, it lacks details on what 'progress' means or how it is derived, 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.
Usage Guidelines2/5
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 among the many siblings. There is no mention of scenarios where this is preferred or excluded, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic function. With no annotations available, it does not disclose any behavioral traits such as filtering semantics, ordering, result limits, or whether knowledge entries from all projects are included by default. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no rhetorical fluff. It immediately states the action and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and six parameters with several filters, the description is too minimal to fully orient an agent. It fails to explain the difference from search_catalog or how filters interact, leaving the agent to rely entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all six parameters (100% coverage). The description adds only a vague sense of content scope ('insights, tips, and lessons learned') but does not elaborate on how parameters like tags, category, or include_general affect the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a search action against knowledge entries and hints at the content type (insights, tips, lessons learned). However, it does not differentiate from sibling tools like search_catalog, which may also perform searches, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as search_catalog or get_document. There is no mention of use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It only says 'Update project settings' without disclosing whether updates are partial or full, destructive, permission requirements, or side effects. Similar to the calibration example for update_drive, this scores 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. However, it is under-specified for the tool's complexity, though that's more relevant to completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no annotations or output schema, the one-line description is insufficient. It doesn't explain return values, whether partial updates are allowed, or consequences of specific parameter changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning about parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates project settings, with a specific verb and resource. It doesn't explicitly distinguish from siblings like setup_project or switch_project, but the verb 'update' provides basic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like setup_project, delete_project, or switch_project. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses project fallback and embodiment option, but omits side effects, permission requirements, or behavior when fields are omitted, which is important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three crisp sentences, front-loaded with the main verb, no filler. Efficiently conveys core action and key fallback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, description fails to explain return value, parameter interplay, or the semantics of completed_task/author, and no annotations or output schema exist to compensate. As a result, the tool remains underspecified for a 7-param write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds grouping (phase, task, blockers) and calls out embodiment, but does not explain parameters like completed_task or author beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the action ('Update session progress') and lists the updateable aspects (phase, task, blockers), making the purpose distinct from session management siblings. It's specific but does not explicitly name alternative tools for similar tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides minimal usage context (project fallback and optional embodiment) but does not specify when to prefer this tool over related tools like update_task_status or get_progress, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Update task status', giving no information about side effects, reversibility, permission requirements, or special behavior like the phase auto-resolve feature mentioned in the schema. It fails to convey important behavioral traits beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. Every word earns its place, and there is no filler or redundancy. It is appropriately concise for a tool with a self-explanatory name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters and no output schema, the description offers almost no context about what happens after the update, what the return value looks like, or how the many optional fields behave. It is incomplete for such a complex tool, lacking details that would help an agent understand the tool's full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters already have descriptions. The tool description adds no parameter-specific meaning, but the baseline of 3 is appropriate given the schema's high coverage. The existing parameter descriptions are terse but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update task status in Google Sheets' clearly identifies the action (update) and resource (task status), and the mention of Google Sheets adds context. It distinguishes from sibling tools like update_task by focusing specifically on status, though it doesn't mention that it can also update category, priority, blockers, etc., which slightly undersells its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 relative to alternatives such as update_task, block_task, or start_task. It simply states what it does without any context about prerequisites, exclusions, or recommended usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action and resource, failing to mention that deletion is irreversible, requires project verification, or has side effects on RAG state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is arguably under-specified for a destructive operation, though concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is purely described by its name and a one-line phrase. Given the lack of annotations and output schema, the description should elaborate on deletion effects, safety checks, and context for use, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (100% coverage). The description adds no extra parameter semantics, but the baseline of 3 applies because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('knowledge entry from RAG'), clearly differentiating from sibling tools like delete_document and update_knowledge. It concisely states exactly 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.
Usage Guidelines2/5
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 (e.g., delete_document for documents). The description does not mention prerequisites, project verification, or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states deletion but doesn't disclose permanence, impact on active sessions, or any side effects. The word 'delete' implies destructiveness, but important behavioral details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and efficient, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with complete schema, the description is adequate but lacks context about irreversibility or how it relates to session lifecycle. The description doesn't explain intended usage in the broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions, so baseline is 3. The tool description adds no parameter information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (delete) and the resource (saved session state for a project). It distinguishes from session lifecycle tools like end_session by specifying 'saved' state, but doesn't explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus start_session/end_session/save_session. The description gives no context about when deletion is appropriate or what distinguishes it from ending a session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention that switching likely sets a current project context affecting subsequent tool calls, nor does it describe any side effects, permission requirements, or failure modes. The description is a bare phrase with no added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized for a simple tool and immediately states the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the basic action but omits important context such as whether the project must already exist, how it affects the current session, or what the result is. It is minimally viable but lacks enough detail for an agent to fully anticipate the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'project' as 'Target project ID to switch to', which is clear and complete. The description adds no significant meaning beyond the schema, so with 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a different project' uses a specific verb ('switch') and resource ('project'), clearly distinguishing it from sibling tools like list_projects, setup_project, or update_project. However, it does not explicitly state that it changes the current working context, leaving slight ambiguity about what 'switch' means in practice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 setup_project or update_project. There is no mention of prerequisites (e.g., the target project must exist) or typical scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral transparency burden. It only states the core action without disclosing side effects, error conditions, or what happens on success or failure. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the tool's purpose, though more detail could be included for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters) and the lack of annotations and output schema, the one-line description is inadequate. It does not explain return values, required field interplay, defaults, or the impact on the progress sheet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptive entries in the schema (100% coverage), so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add a new task') on a specific resource ('the progress sheet'). This distinguishes it from sibling tools like update_task, complete_task, and delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as update_task or start_task. The purpose is implied but there are no explicit exclusions, prerequisites, or references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'get', implying a read operation, but does not disclose error behavior (e.g., not found), permissions, or the role of the required phase parameter. There is no contradiction, but the transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It efficiently conveys the core purpose without additional fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 required, including 'phase' which has nuanced behavior ('empty string for auto-resolve from unique match') that is only present in the schema. The description does not explain why phase is required or how the get operation behaves. With no output schema or annotations, the description is too sparse for a tool with these complexities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (task_id, phase, user, project) having a description. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single task by ID' clearly states the verb (get), resource (task), and scope (single by ID). This distinguishes it from sibling tools like add_task, delete_task, and update_task, and makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no context such as 'use for retrieving a specific task when you know its ID', and no exclusions. It simply states the operation without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies a read-only operation through 'List,' but does not explicitly state safety, authentication needs, return format, or any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loaded with the verb 'List.' Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the one-sentence description is insufficient. It doesn't describe the response shape, behavior when project is omitted (though the schema notes this), or other usage nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds nothing beyond the generic mention of filtering and pagination, which the schema already details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List') and resource ('documents'), scoped to 'in a project' with 'filtering and pagination.' This distinguishes it from sibling tools like get_document (single document) and list_document_types (types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search_catalog or search_knowledge. It simply states what it does, without mentioning exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It merely says 'sync' without explaining whether it is a full refresh, whether existing cache data is overwritten, what permissions are required, or how failures are handled. The operational impact remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the core action and main entities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, the sync operation has significant unaddressed behavior: idempotency, data replacement, error conditions, and prerequisites. The absence of annotations and output schema increases the burden on the description, which it fails to meet, leaving the tool under-specified for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the sole parameter 'project' with a complete description, so the schema already provides full semantic meaning. The description adds no extra parameter context, placing this at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sync'), the source ('Google Sheets'), the destination ('RAG cache'), and the resource ('the catalog'). This distinguishes it from sibling tools like sync_projects_from_drive, which target projects rather than the catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sync_projects_from_drive or search_catalog. It neither states explicit use cases nor exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 explaining whether fields are merged or overwritten, whether the summary sheet is created if missing, what permissions are needed, or what response to expect. This lacks critical behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource immediately. It contains no filler and is appropriately concise for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six optional parameters, a nested custom_fields object, no output schema, and no annotations, the description is not contextually complete. It omits essential information such as whether unspecified fields are preserved, how custom_fields interacts with standard fields, and what occurs if the summary sheet does not exist. This leaves significant gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have descriptions in the schema, giving 100% coverage, so the baseline is 3. The description's mention of 'description, current phase, and task counts' simply restates schema fields and adds no extra meaning about relationships, constraints, or usage peculiarities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies an update operation targeting the 'project summary sheet' and lists relevant fields such as description, current phase, and task counts. This distinguishes it from sibling tools like update_project, update_task, and update_document, which operate on different resources. The phrasing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like update_project or update_task, nor does it mention any exclusions, prerequisites, or contextual cues. The intended use is only implied by the operation name and listed fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It implies a read-only check but introduces ambiguity with 'collection/schema auto-creation status' – it's unclear if the tool triggers creation or merely reports status. It does not disclose side effects, failure modes, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, immediately front-loaded with the primary purpose and a parameter tip. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with one optional parameter, the description covers the core purpose and parameter. However, it lacks details on return values or response structure, and the auto-creation ambiguity leaves some contextual gaps. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the 'detailed' parameter. The description adds a minor usage note ('Use detailed=true for protocol, latency, and other detailed info') but largely repeats schema information. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks connection status of RAG and Memory servers and verifies server availability and collection/schema auto-creation status. It uses specific verbs and resources, distinguishing it from sibling tools like get_connection_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The only usage instruction is about the 'detailed' parameter, not about selection context. No mention of exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the mutation (sets status to completed) but does not discuss permissions, reversibility, side effects on notes, or error conditions. This is insufficient for a mutating tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the primary action. Each word contributes; 'convenience method' adds a bit of flavor but doesn't distract. Excellent for size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation, the description covers the core action, but lacks context about when to use it (given siblings), required prerequisites, or behavioral caveats. The presence of 'convenience' suggests an alternative but doesn't explain it. With no output schema or annotations, this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond the schema. It doesn't explain the role of phase or project, but the schema already provides basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark a task as completed') and defines what it does ('sets status to completed'). It's specific to the task resource, but doesn't explicitly differentiate from sibling update_task_status, relying on 'convenience method' to imply specialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'convenience method' implies a shortcut but does not explicitly state when to use this tool versus update_task_status or other task operations. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that it adds a knowledge entry, but provides no details on idempotency, requirements (e.g., active session/project), return values, error cases, or whether duplicates are checked. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and purpose. Every word serves a function, and there is no wasted text or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what happens after adding (e.g., return value, ID), any prerequisites like an active session/project, or how to handle potential errors. The presence of sibling tools like start_session and setup_project suggests dependencies that are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description does add context about content types (insights, tips, best practices) that aligns with the category enum, but it does not add extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('knowledge entry to RAG'), and lists the types of content intended ('insights, tips, best practices, and lessons learned'). This clearly distinguishes it from sibling tools like update_knowledge or delete_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to store new knowledge, but it does not explicitly mention when to use this tool instead of update_knowledge or search_knowledge. No exclusion criteria or alternative tools are named, so the guidance is only at an implicit level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It states the action but not side effects, such as whether it changes status, appends to a blockers list, or triggers notifications. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, and free of redundancy. It efficiently conveys the core purpose without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain prerequisites, effect on task status, and behavior around auto-resolution. It omits all of that. The description is adequate for a very simple tool but lacks depth for a 4-parameter mutation with required phase and project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond the schema. It mentions 'blockers list', aligning with the blockers parameter, but does not provide extra meaning for phase, project, or task_id beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') plus resource ('task') and outcome ('as blocked with blockers list'). It clearly distinguishes from sibling tools like complete_task or start_task by specifying the blocked state and blockers input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies use when a task becomes blocked, but there is no explicit when-to-use, exclusions, or comparison to alternatives like update_task_status. The usage guidance is implied by the verb 'blocked' rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It mentions saving state and the optional embodiment field, but does not explain the consequences of ending a session (e.g., whether it can be resumed, whether it is irreversible, or whether related resources are cleaned up). This is a significant gap for a session-terminating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and avoids redundancy with the schema. Every phrase contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 optional parameters and no output schema, yet the description is brief. It covers the main action and two parameter behaviors, but lacks detail on session end semantics or return values. Considering the absence of annotations, the description is minimal but not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 7 parameters (100% coverage), so baseline is 3. The description adds value by explaining that project defaults to the current project if omitted and that embodiment is recorded on the saved SessionState, offering context beyond the schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'End the session and save state.' It identifies the resource (session) and outcome (save state), making it distinct from listing or updating sessions. However, it does not explicitly differentiate from save_session, which could also save state without ending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use end_session over save_session or other session tools. The only contextual note is that it uses the current project if project is omitted, which is more of an input behavior than a usage guideline. No exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it writes settings to config.toml, indicating a persistent mutation. However, it does not mention validation, error handling, whether changes take effect immediately, or if a restart is required. With no annotations, this leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that immediately state the action and target. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with complete parameter documentation, but the description omits return values and post-write behavior. Given no output schema, this is a gap. However, the description is a minimal viable for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (setting and value) with examples for setting. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as updating the Spirrow-Prismind configuration by writing to config.toml. This distinguishes it from sibling tools like export_server_config and import_server_config, which handle config import/export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any preconditions, whether to use it alongside import/export, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action but does not disclose what 'registered projects' means, return shape, ordering, pagination, or any side effects. The description adds minimal behavioral context beyond a literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. There is no redundant or filler content, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple parameterless list tool, the description is minimally adequate, but it lacks details about the output format or any filtering behavior. Since there is no output schema and no annotations, the description should compensate by explaining what a 'registered project' is or how the results are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% vacuously. Per rubric, zero params earns a baseline of 4; the description need not add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('list of registered projects'), making it clear what the tool does. It inherently distinguishes itself from sibling list tools like 'list_sessions' and 'list_documents' by naming the resource 'projects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. Given many sibling 'list_*' tools, the description should at least hint at the distinction or exclusions, but it gives none.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only says 'Update'. It does not mention that only provided fields are changed, that the entry must exist, or what response is returned. The schema's 'omit to keep unchanged' is useful, but it is not part of the description and does not carry the burden for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Update an existing knowledge entry.' No filler, front-loaded with verb and object, and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward CRUD update with a well-specified schema, so the description is mostly sufficient. However, there is no output schema and the description does not indicate what the tool returns (e.g., updated entry, success flag) or any error conditions, leaving a minor gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described clearly (e.g., 'New tags (omit to keep unchanged)'). The description adds no extra meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update') and target ('an existing knowledge entry'). The word 'existing' distinguishes it from add_knowledge (create) and delete_knowledge, so it differentiates from sibling tools effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (updating an already-created entry), but provides no explicit guidance on when to prefer this tool over alternatives like add_knowledge. The schema's 'omit to keep unchanged' hints at partial-update semantics, but the description itself does not give usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses validation and error reporting but omits critical behaviors like whether the import overwrites existing configuration, requires permissions, or what happens on success. 'Import' suggests a mutation, but the destructive or reversible nature is unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the core purpose and immediately follow with the validation behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain side effects and return format. It only mentions error reporting, but not success behavior, whether the config is replaced, or any prerequisites. This is insufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the 'config' parameter is described as 'Configuration content in TOML format'. The tool description does not add additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource 'shared server configuration', distinguishing it from sibling tools like export_server_config. It also mentions validation, which adds specific functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing shared configuration, and the name differentiates from export_server_config. However, it lacks explicit when-to-use vs alternatives or exclusions, such as when to use configure instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions filters but fails to clarify the significant default behavior: when 'user' is omitted, it uses the current user, which may conflict with the phrase 'all saved sessions'. It also does not state whether the operation is read-only or if any side effects occur. This is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two short sentences and immediately front-loads the core purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action but leaves out key contextual details like the default user filter scope, the meaning of 'saved sessions', and any pagination or ordering behavior. Given no output schema and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters with descriptions, and the tool description only restates the filtering capability. No additional meaning or format details are provided beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('saved sessions'), clearly distinguishing it from session lifecycle tools like save_session, start_session, or delete_session. The optional filter by project/user is also stated, making the tool's scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only listing use case, which is clear from the name and sibling context. However, it does not explicitly state when to use this instead of other session tools or mention exclusions, so it falls short of 'explicit when/when-not' guidance. Clear context but no alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention side effects like auto-creating folders, applying templates, or custom fields, nor does it explain permissions, reversibility, or idempotency. For a mutation tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that clearly state the purpose and the key scope decision. No wasted words or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 8 parameters and no output schema, the description only covers purpose and scope. It omits important context such as what the response looks like, prerequisites, side effects (e.g., folder creation, template handling), and how to handle conflicts. While the schema fills in parameter details, behavioral and environmental context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so parameters are well-documented in the schema. The description adds a brief clarification of the scope parameter, but this mostly repeats the schema's explanation. It does not provide significant additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states clearly that the tool registers a new document type, with a specific verb and resource. It also distinguishes itself from sibling tools like list_document_types, delete_document_type, and find_similar_document_type by focusing on creation/registration and noting scope options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to register a new document type) and gives explicit guidance on scope values (global vs project), which helps agent choose the correct setting. However, it does not mention alternatives or when not to use this tool, such as checking for existing types with find_similar_document_type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explicitly states the mutation by noting it sets status to 'in_progress', which is transparent about the core behavior. However, it does not disclose potential side effects, permissions, or additional constraints beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the main action. The second sentence is largely redundant with the first, creating minor waste, but overall it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three parameters and no output schema, the description covers the essential purpose. However, it does not place the tool in context among sibling task operations or explain when to use alternatives, leaving a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description adds little to parameter meaning, only implying that the status becomes in_progress. Baseline 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks a task as in progress, using a specific verb and resource. It explicitly defines the outcome as setting status to 'in_progress', which distinguishes it from sibling tools like update_task_status or complete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'convenience method' but does not provide explicit when-to-use guidance or name alternatives. It doesn't state when to use this tool versus update_task_status or other task status tools, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that updates can be partial ('any combination of fields'), which is key behavioral context. However, it does not explain side effects, list replacement vs merge semantics, validation rules, or permission requirements, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists fields efficiently. It is slightly long due to the field enumeration but each element earns its place, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is moderately complete. It identifies all updatable fields but omits key invocation context such as why 'phase' is required and the auto-resolve behavior described in the schema. The description alone would leave an agent uncertain about required parameters for correctly targeting the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by grouping fields and clarifying that 'moving to a new phase' is supported, but it mainly reiterates what the schema already states. No significant new parameter meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a task and lists specific updatable fields (name, description, status, priority, category, blocked_by, blockers, and moving to a new phase). It distinguishes from sibling tools like update_task_status, start_task, complete_task, and block_task by emphasizing 'any combination of fields' and including phase movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general task updates ('any combination of fields') but does not explicitly mention when to use this tool versus alternatives like update_task_status or start_task. It lacks explicit exclusions or guidance for specialized status-change tools, leaving usage somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It clearly states the action is 'Delete,' implying a destructive operation, but does not explain potential side effects (e.g., impact on documents using the type), reversibility, or any required permissions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded. Every sentence provides useful information: the action and the scope guidance. There is no fluff or repetition of schema details, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter delete tool with full schema coverage, the description covers the essential action and scope behavior. However, it omits side-effect context, such as what happens to documents associated with the deleted type, which is relevant given the sibling tool delete_document exists. This leaves the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions, setting a baseline of 3. The description adds meaningful value by explaining how to choose scope='global' vs 'project', which is not fully captured in the schema's generic phrase 'Type scope to delete from.' This extra guidance elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Delete a document type.' It clearly distinguishes from sibling tools like delete_document by naming the resource type. It also adds useful scope distinction (global vs project), which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using the 'scope' parameter ('Use scope='global' for global types, or scope='project' for project-specific types'), which helps with invocation. However, it does not explicitly state when to use this tool versus alternatives like delete_document or list_document_types, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses an important side effect (cleaning blocked_by references), but does not mention whether deletion is permanent, if permissions are required, or what happens if the task 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and immediately followed by the side effect. It is concise and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description gives the essential purpose and side effect. However, it lacks clarity on the deletion behavior (e.g., reversibility, constraints, impact on dependent tasks beyond blocked_by), leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all four parameters (user, phase, project, task_id), so the baseline is 3. The description does not add extra meaning beyond the schema, but the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (delete) and resource (task from progress sheet), and uniquely mentions the blocked_by cleanup, distinguishing it from sibling task tools like update_task or get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a task needs to be deleted, but it does not explicitly mention alternatives, exclusions, or prerequisites. It is clear enough that this is the delete operation for tasks, but lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the responsibility of disclosing behavior. The verb 'Get' and 'Shows' imply a read-only operation, but the description does not explicitly state safety, side effects, authentication needs, or potential latency. It adds some context by listing the returned information but lacks explicit behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No redundant filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter getter tool with no output schema, the description adequately explains the return content (status, latency, version info for three services). It does not describe error conditions or response format, but given the low complexity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context about what the tool returns, which is sufficient given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'connection information', and further specifies what it shows (status, latency, version info) for three named services. This is clear, though it does not explicitly differentiate from sibling tools like check_services_status or get_setup_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking connection information but does not state when to prefer this tool over alternatives such as check_services_status or get_setup_status. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It discloses loading saved state and recording embodiment, but it does not mention whether starting a session overwrites an existing session, requires an active project, or what side effects occur. This is a significant gap for a stateful operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the main action, with each parameter explained in a separate clause. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function, parameter defaults, and optional behavior. However, it omits prerequisite conditions and return values, which would be helpful for a session-starting tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly paraphrases the schema: 'Uses current project if project is not specified' mirrors the project parameter description. It adds little additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start a session and load saved state.' It distinguishes from siblings like save_session and end_session by focusing on initiation and restoration. The first sentence uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context on when to use parameters: 'Uses current project if project is not specified' and 'Specify author to restore a specific context-author/role partition.' This gives clear guidance on default behavior and when to specify author, but doesn't explicitly compare with alternatives like get_setup_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 reveals the underlying mechanism (RAG-based, BGE-M3 embeddings, multilingual matching) and provides a clear example, which goes beyond a simple read operation. However, it does not mention return format or whether it is read-only, though 'find' implies a non-destructive search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences total. The first sentence immediately states the primary purpose, and the second adds method and a concrete example. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers purpose and method well. However, it does not specify the return value shape (e.g., list of matches with scores, single best match). Since there is no output schema to compensate, this is a notable gap for an AI agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (type_query and threshold) already documented. The description adds an example of type_query but does not further explain the threshold behavior beyond the schema's 'Minimum similarity score'. Thus, the description provides marginal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Find a document type semantically similar to the query') and distinguishes it from sibling tools like list_document_types by emphasizing semantic search. The concrete example ('api仕様' -> 'api_spec') reinforces the specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need semantic matching rather than exact lookup) but does not explicitly state alternatives or exclusions. It does not mention 'use instead of X' or 'not for exact matches', so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool is non-destructive ('without ending the session') and that it falls back to the current project. However, it does not disclose whether saving overwrites existing state, merges data, requires permissions, or what the response contains. Some useful traits are provided, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that get straight to the point. It front-loads the core purpose, then adds a key default behavior and an optional field note. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema documents all 9 parameters, the description provides limited context for a tool with no annotations or output schema. It explains the project default and mentions embodiment, but it does not clarify how other fields (notes, summary, blockers) are handled, whether state is overwritten, or what happens on success. It is adequate but not fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the project default and highlights 'embodiment' as optional, but the schema already provides these details (e.g., 'uses current project if omitted' for project). No new semantic meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save session state without ending the session.' This specifies the verb (save), the resource (session state), and explicitly distinguishes it from ending a session, which differentiates it from sibling tools like end_session. It also mentions the project default behavior, adding scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it saves state mid-session (not ending it) and uses the current project if none is specified. This implies when to use it, but it does not explicitly contrast it with alternatives like update_session_progress or provide exclusion criteria. It is useful but could be more explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool will add/remove projects, which indicates a mutating operation. However, it does not elaborate on the potential consequences of removing projects (e.g., cascading deletion, data loss) or permission requirements. The dry_run parameter is not mentioned in the description, though it is in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at two sentences, front-loaded with the primary action, and contains no unnecessary words. Every phrase contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the tool returns (e.g., a summary of changes). It also assumes familiarity with 'projects_folder_id' and does not mention prerequisites. The core behavior is covered, but some operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (dry_run) with 100% coverage, so the baseline is 3. The description adds context about what 'differences' mean (folder list vs RAG), but does not enhance the dry_run parameter's meaning beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Sync'), the resource ('folder list under projects_folder_id in Google Drive'), and the relationship with RAG. It explicitly states that Drive is the master source for adding/removing projects, which distinguishes it from sibling project management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Uses Drive as master', implying the tool should be used when Drive should dictate the project list. However, it does not explicitly mention alternatives or when not to use the tool, so it lacks full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description has full burden for behavioral disclosure. It adds that deletion also affects catalog entries and that project name is required for safety. However, it doesn't mention permissions, reversibility (soft vs permanent), or drive file handling beyond schema. Some value added, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary action and a key safety constraint. Without an output schema, it doesn't describe response format, but this is acceptable for a delete tool. Context on perm vs soft delete exists in the schema, so it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description doesn't add param-specific semantics beyond what the schema already provides; the mention of 'project name to prevent accidental deletion' echoes the schema's required project with a safety rationale, which is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'a document and its catalog entries,' making the tool's function clear and distinguishing it from sibling tools like update_document or delete_document_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when deleting a document and mentions a safety requirement (project name), but it does not explicitly contrast with other delete tools (e.g., delete_document_type) or provide when-not scenarios. Clear context, but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior fully. It says 'Get' and 'Shows', which imply a read-only operation with no side effects, but it does not explicitly state that it is non-mutating, nor does it mention prerequisites, error conditions, or permissions. The verb choice gives a reasonable hint, but more transparency would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, concise, and front-loaded with the main purpose. The second sentence adds relevant detail about what is shown, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-check tool, the description provides sufficient context: what resource is being inspected and what state information is returned. It does not describe the exact response format, but that is less critical given the simplicity of the tool and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanations are needed. The schema already reflects this with an empty object. The description correctly omits parameter details, and the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves configuration status for Spirrow-Prismind and specifies that it shows required and optional settings with their configured/unconfigured state. This distinguishes it from siblings like configure (which modifies settings) and check_services_status (which checks service health).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking setup status but does not explicitly mention when to use it vs. alternatives such as export_server_config or get_connection_info. There is no direct 'use this when...' wording or reference to sibling tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auto-creation side effect for spreadsheet and folder when IDs are omitted. However, it does not mention confirmation behavior (force parameter), effects on existing projects, or error handling, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and only includes the essential conditional detail about auto-creation. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, the description lacks critical context for a complex tool with 8 parameters and no annotations or output schema. It does not explain return values, the force confirmation flow, create_sheets/create_folders booleans, or what happens if the project already exists. The description is too minimal for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all 8 parameters with clear descriptions. The description adds value by explaining that spreadsheet_id and root_folder_id are auto-created under the projects_folder_id from config.toml, which clarifies the semantics of these optional parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Set up a new project' and adds a specific behavioral detail about auto-creating resources when IDs are omitted. This distinguishes it from sibling tools like update_project or delete_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for new project creation and explains the conditional auto-creation behavior, giving context for when this tool is appropriate. However, it does not explicitly exclude cases like updating existing projects or compare with alternatives such as switch_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that each entry includes an 'identity' object (or null) joined from the cross-project identity record, enabling callers to see allowed_roles without a second lookup. While it doesn't cover every trait (e.g., pagination), it meaningfully discloses return structure and join behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences of substantive content: purpose, usage guidance, and a return-value detail. It is front-loaded with the primary action and each sentence earns its place, though the third sentence is somewhat dense and could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description is quite complete for a list tool: it states the scope, explains a key return field (identity), and gives usage context. It lacks explicit mention of sorting, pagination, or error cases, but remains strong for typical list operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters ('project' and 'user'), so the description doesn't need to explain them. It mentions 'project' in context but adds no extra semantic detail beyond the schema, thus the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'distinct context authors/roles' and scopes it to 'saved session state for a project.' It clearly distinguishes itself from sibling tools like get_identity and upsert_identity by focusing on existing context authors rather than identity management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'avoid creating duplicate contexts from naming variations' and 'check whether your own author's context already exists.' It also references upsert_identity for related actions, but does not explicitly state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful semantics beyond a simple 'get' by explaining that global and project-specific types are returned and that project type takes precedence on type_id conflict. However, it does not explicitly state side effects (e.g., read-only) or error behavior, though 'Get' implies no changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and every sentence adds value. It avoids filler and clearly conveys the core behavior and a key precedence rule. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description reasonably explains what the tool returns (global and project-specific types) and the precedence rule. It could be more complete by mentioning the fields included in each type, but for a parameterless list tool the main behaviors are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description does not need to explain parameter semantics, and the baseline for 0 parameters is 4. No additional parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get a list of available document types.' It distinguishes itself from sibling tools like register_document_type and delete_document_type by indicating it is a read-only listing operation. The detail about global and project-specific types adds specificity without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to enumerate document types, but it does not explicitly state when to use this tool over alternatives such as find_similar_document_type or register_document_type. There is no mention of exclusions or alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating the output format (TOML) and that sensitive information (paths) is excluded, which gives the agent insight into the response content and privacy handling. However, it does not explicitly mention that the operation is non-destructive or any authentication prerequisites, though the verb 'export' implies read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each earning its place. The first states the action and purpose, the second details the output format and exclusion policy. There is no redundancy or fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description covers the core aspects: purpose, output format, and data exclusion. However, it does not specify whether the output is a string or a file, nor any prerequisites like prior setup, which are minor gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema leaves no ambiguity. The description adds context about the output format and exclusion of paths, which is more relevant than parameter details. The baseline of 4 is appropriate because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and resource 'server configuration,' and specifies the purpose 'for team sharing.' It also differentiates from siblings like import_server_config by mentioning the TOML format and exclusion of sensitive paths, making the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('for team sharing') and implies a complementary relationship with import_server_config, but it does not explicitly name alternatives or state when not to use it. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: persistence in a distinct key space, required re-declaration of independence_class, preservation semantics for allowed_roles and persona_description, and deprecation of embodiment with migration guidance. It clearly states the '書き忘れ不能' guarantee, which is behavior, not already present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, with each sentence conveying a distinct piece of behavioral or semantic information. While somewhat lengthy and technically terse (ADR references), it is appropriately sized for a tool with 7 parameters and complex update semantics, containing no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential behavioral context: key space, required fields, preservation defaults, deprecation, and relation to list_context_authors. It does not explicitly discuss return values or error conditions, but for a tool with this complexity, the narrative is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explaining the 're-declared, not preserved' guarantee for independence_class, the distinction between empty list [] and preserve for allowed_roles, and the deprecated embodiment's schema-only retention. These enrich the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create or update an identity record (cross-project actor declaration)'. It clearly distinguishes this from read-only siblings like get_identity and list_context_authors by centering on creation/update semantics and persistent storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool, including the relationship to SessionState.author and mentions that list_context_authors joins the identity record for one-round-trip reads. It does not explicitly contrast with get_identity, but the provided context and parameter interaction guidance (required fields, preservation defaults) sufficiently imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses read-only safety, cross-project scope, the user fallback behavior, and the two-state response semantics ('not registered' vs 'lookup failed') with a recommendation to fail closed on the latter. This is rich behavioral context beyond what any annotation would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but dense, with the core action front-loaded and every sentence contributing either scope, guidance, or behavioral semantics. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return distinction and its implications for callers. It also covers cross-project behavior, relation to sibling tools, and edge cases (fallback, fail-closed). The tool is fully contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds relational context beyond the schema: the user param's fallback is explicitly tied to upsert_identity, and identity_name is identified as the same value used in SessionState.author / upsert_identity. This helps disambiguation and compensates for missing cross-references in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and resource ('ONE identity record by name') and specifies scope ('cross-project, read-only'). It clearly distinguishes itself from the sibling tool list_context_authors, stating what get_identity does that the sibling cannot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you need a specific actor's allowed_roles / independence_class') and names the alternative to avoid (list_context_authors), with a concrete reason why the alternative is inadequate. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![spirrow-prismind MCP server](https://glama.ai/mcp/servers/SpirrowGames/spirrow-prismind/badges/card.svg)](https://glama.ai/mcp/servers/SpirrowGames/spirrow-prismind)

Score Badge

Copy to your README.md:

[![spirrow-prismind MCP server](https://glama.ai/mcp/servers/SpirrowGames/spirrow-prismind/badges/score.svg)](https://glama.ai/mcp/servers/SpirrowGames/spirrow-prismind)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpirrowGames/spirrow-prismind'

If you have feedback or need assistance with the MCP directory API, please join our Discord server