Personal DB MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools follow a clear resource+action pattern (create/get/list/update/delete for each entity type like profile, skill, project), so they are largely distinguishable. However, a few tools overlap conceptually: 'search' (full-text search across all tables) and 'get_stats'/'get_context' have some ambiguity in purpose, and 'persona' vs 'profile' represent potentially overlapping concepts. Overall the resource-based naming keeps boundaries mostly clear.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun pattern (create_X, get_X, list_X, update_X, delete_X) in snake_case, which is excellent. Minor deviations exist: 'search', 'tag_entry', 'untag_entry' reverse the order to noun_verb, and a few like 'generate_nft_snapshot' and 'preview_nft_data' use different verb forms. Also 'get_stats', 'get_context', 'debug_auth', and 'analyze_profile' don't match the CRUD pattern. Still, the deviation is small relative to the ~90 tools that do follow the pattern.
Tool Count1/5
101 tools is extremely high, far exceeding reasonable scoping for any server. While a personal database could legitimately manage many entity types, having 101 distinct tools creates massive cognitive overhead. Each entity type generates 5 CRUD tools plus auxiliary tools, resulting in a sprawling surface. This is a textbook example of tool-count bloat that will overwhelm agents.
Completeness3/5
CRUD coverage is quite thorough for most entity types (profile, skill, project, achievement, episode, education, hobby, values, health, life events, relationships, goals, custom categories/entries, personas, careers). However, there are gaps: delete_relationship, update_relationship, get_relationship, list_relationships exist but no... actually most are present. Missing delete for relationship and goal's get/delete gaps — delete_goal exists but check list. Some entities like NFT and tags have partial coverage (no create/update NFT, no delete tag). Overall coverage is good but not complete across all entity types.
Average 2.6/5 across 101 of 101 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 fails to state whether this is a PATCH-like partial update or full replacement, whether unspecified fields are preserved or reset, what happens on conflict, or what the response contains. The bare statement conveys only that this tool mutates a project.
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 a single short sentence, which is technically concise, but this is under-specification rather than genuine conciseness. One tautological sentence does not earn points for efficiency since it conveys no meaningful content beyond the tool name.
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?
This is a mutation tool targeting a complex entity (many nested fields: tags, lessons, outcomes, metadata, technologies) with a nested data object, no output schema, no annotations, and a tautological description. The description is completely inadequate for guiding an agent through a multi-field partial update with nested-object semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds nothing beyond the schema. The description doesn't explain that 'data' is a partial-update payload, the relationship between id and data, or how nested objects like metadata and tags behave. With only half the parameters documented in the schema and zero description contribution, the coverage gap is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "プロジェクトを更新" (Update project) is essentially a tautology that restates the tool name. It uses the verb 'update' plus resource 'project' with no additional scope, semantics, or distinction from the many sibling CRUD tools like update_career_entry, update_skill, update_goal etc. No differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided whatsoever. There is no statement about when to use this tool, when not to use it, prerequisites (e.g., must the project exist first?), or whether partial updates are supported. The description offers zero guidance on alternatives or appropriate invocation contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, and it completely fails. It doesn't state whether this is a read or mutation operation, whether authentication is required itself, what side effects occur, whether it's safe, or what the agent should expect as a result. The description adds essentially zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single Japanese phrase is technically minimal (one token), but this is under-specification, not conciseness. A 3-word description without any structured detail does not earn the tool's size. There's no front-loading of key behaviors because there's virtually no content at all.
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 parameters, no output schema, and no annotations, and the description is a bare 4-character phrase. While it's a zero-parameter tool, the complete absence of behavioral context and usage guidance makes it inadequate. Some threshold of explanation is still warranted for a tool named 'debug_auth' with zero structured metadata.
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 0 parameters, so there is nothing to describe beyond the schema. With 100% schema coverage and no params, the baseline of 4 applies — there is genuinely nothing more the description could add about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '認証デバッグ' (Authentication debug) provides only a vague, high-level purpose. It names a resource (authentication) but offers no verb/action specificity — it doesn't say what actions are performed (e.g., verify, reset, test). It also doesn't distinguish this from siblings, which are mostly CRUD tools for various domain entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance whatsoever is given on when to use this tool vs alternatives. The empty description provides no context for when authentication debugging is appropriate, no prerequisites, and no exclusions. The agent would have no idea when to invoke this versus any other tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only says 'delete' without revealing whether deletion is permanent/irreversible, whether it cascades to tags or related data, whether any confirmation is needed, or what happens to associated relationships. For a destructive operation with zero annotation coverage, this is a critical gap.
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 extremely brief (one short sentence), which is efficient, but it crosses the line from concise to under-specified. Every word earns its place but the description is too minimal to be genuinely useful.
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?
This is a destructive delete operation with no annotations, no output schema, and only a tautological description. It fails to explain irreversibility, cascading effects, ownership/permission requirements, or any error conditions. For a mutation tool, the description should communicate substantially more than 'delete custom entry'.
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 covers 100% of parameters with a single 'id' field described as an entry ID (UUID). The description doesn't need to add much since there's only one parameter and it's fully documented in the schema. The baseline-3 applies, and the clear UUID type documentation raises it slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'カスタムエントリを削除' (Delete custom entry) clearly states the verb and resource, but it's a tautology of the function name itself (delete_custom_entry). It distinguishes minimally from siblings like delete_custom_category, but provides no additional context about what a 'custom entry' is or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. There is no mention of when custom entries should be deleted, what constrains deletion, or any relationship to the many sibling CRUD tools (create_custom_entry, get_custom_entry, list_custom_entries, update_custom_entry).
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 fails to state that this is a mutating write operation (which could affect existing data), whether partial updates are supported (only the data object fields present get updated), whether a non-existent id causes an error, or what the return value is. For a mutation tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely under-specified — just four characters ('経歴を更新') that merely restate the tool name. This is not conciseness but a failure to communicate. No useful information is conveyed beyond what the tool name already implies.
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 2 parameters (one of which is a deeply nested object with 15 fields), no output schema, no annotations, and moderate schema coverage, the description should provide substantial context. It provides essentially none. The agent cannot determine what gets updated, whether this supports partial vs full replacement, error handling, or what a successful update returns. The complex nested data structure makes this particularly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, meaning the schema documents only a subset of the parameters. The data object has 15 nested properties which are individually described in the schema with Japanese descriptors, but the description adds nothing beyond what the schema provides. The description doesn't explain the relationship between the two required parameters (id and data), the semantics of partial updates, or the intent of the more obscure fields. With moderate coverage and a complex nested object, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '経歴を更新' (Update career history) is a tautology that essentially restates the tool name. It identifies the verb 'update' and the resource 'career entry', but provides no additional specification about what fields can be updated, what the update scope is, or how it differs from sibling tools like update_education, update_skill, update_project, etc.
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 gives no guidance on when to use this tool versus alternatives like update_education, update_skill, update_project, update_achievement, or the create/get/list career entry siblings. There is no indication of prerequisites (e.g., the entry must exist first), no mention that id must reference an existing career entry, and no exclusions or context about when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. 'Update' implies mutation, but nothing states whether partial updates are supported, whether the 'data' object fully replaces existing fields, what happens to omitted fields, auth/permission requirements, or return behavior. Zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single minimal phrase 'ペルソナを更新' with no additional information. While nominally concise, this is under-specification rather than economy—the sentence earns no placement because it contributes essentially nothing beyond the tool name itself.
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?
This is a complex mutation tool with a large nested 'data' object (15+ fields), no annotations, and no output schema. Given this complexity, the description is dramatically under-specified. It doesn't explain update semantics, field substitution behavior, or the relationship to server-side persona processing. Far from complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with 2 top-level params (id, data). The 'data' nested object has extensive per-field descriptions, but the description adds nothing beyond the schema. The 'id' parameter is self-documenting. The description neither compensates for the 50% coverage gap nor harms it; baseline 3 for partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'ペルソナを更新' (Update persona) is a near-tautology of the tool name 'update_persona'. It identifies the verb (update) and resource (persona) but adds no scope, semantics, or distinction from siblings like create_persona or list_personas. Minimal functional 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 on when to use this tool vs alternatives. With siblings like create_persona, get_persona, list_personas, and list_available_personas, there is no context distinguishing update-from-create (e.g., 'use for existing personas only, requires an existing id') or prerequisites. No implied usage beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description only states 'delete goal' with no mention of destruction irreversibility, cascade effects on related entries, permission requirements, or any side effects of deletion. For a destructive operation with zero annotation coverage, this is a major gap — the agent has no way to know deletion is irreversible or what collateral damage may occur.
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 phrase, so it is concise in length. However, it is under-specified rather than genuinely concise — it says almost nothing beyond the tool name. This is not efficient compression of useful information but rather a minimal placeholder.
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 destructive mutation tool with no annotations, no output schema, and a one-line tautological description, the description is severely inadequate. It should clarify the entity being deleted, irreversibility, prerequisites (an existing goal), and any cascade effects on related data.
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 description coverage is 100% and there is only one parameter. The schema documents 'id' as an entry ID (UUID), which fully specifies the required input. With a single, well-documented parameter at 100% coverage, the description has little additional burden to carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '目標を削除' (delete goal) restates the tool name almost verbatim — 'delete_goal'. It's a tautology that simply translates the function name and adds no specificity about what a 'goal' is or what kind of deletion occurs (e.g., hard vs soft delete). For a tool with no title, the description should clarify what a goal represents in this domain.
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 delete_goal versus similar delete tools among siblings (delete_skill, delete_project, delete_achievement, delete_hobby, etc.). There's no mention of prerequisites, e.g., whether a goal must be fetched first or whether deletion cascades to related entries. Users would need to infer usage purely from the entity type name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not disclose whether deletion is permanent/irreversible, whether related entries (tags, relations) are affected, whether auth is required, or what happens to associated data. For a destructive tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, so there is no waste, but this is under-specification rather than genuine conciseness. For a destructive operation that warrants behavioral explanation, brevity here reflects lack of useful content rather than efficient prose.
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?
This is a destructive tool with no annotations and no output schema, so the description should compensate. With a single line merely restating the tool's purpose, the description is inadequate for conveying the full implications of deletion. The 100% schema coverage mitigates the parameter side, but behavioral completeness 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?
Schema description coverage is 100% with one parameter (id, UUID). The schema already documents the parameter fully, so the description adds nothing beyond the baseline. According to the rubric, with high coverage the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '趣味を削除' translates to 'Delete hobby,' which states a verb and resource but is essentially a tautology of the tool name 'delete_hobby.' It adds no detail about scope, what exactly gets deleted (single hobby entry by UUID), or cascading effects, and does nothing to distinguish this from the many similar delete_* sibling tools beyond the name itself.
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 delete_custom_entry or other delete_* tools. The name makes intent somewhat clear, but no exclusions, prerequisites, or context are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'スキルを削除' does not disclose whether deletion is permanent/reversible, requires confirmation, affects related entries (e.g., entries referencing this skill), or has any side effects. For a destructive operation with zero annotation coverage, this is a critical gap.
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 extremely short (single phrase). While concise, it's more under-specification than intentional brevity. It conveys minimal information but is certainly not verbose or wasteful.
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 simple (1 parameter, no output schema), which lowers complexity. However, it's a destructive operation with no annotations, no behavioral disclosure, and no explanation of consequences. For a delete operation, the description is inadequate even at low 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 'id' parameter is fully documented as an entry UUID in the schema. The description adds nothing about the parameter, but baseline 3 applies since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'スキルを削除' (Delete skill) states a verb+resource but provides no scope, no behavior details, and no differentiation from the many sibling delete_* tools. It's minimal and functional but lacks specificity about what 'skill' refers to or any distinguishing context.
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 alternatives. While it's obvious from the name that it deletes skills, there's no mention of prerequisites, cascading effects, or when NOT to use it. No alternatives referenced.
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's a mutation operation (implied by 'update') but says nothing about whether fields are merged or fully replaced, whether id must exist, whether missing optional fields are preserved or cleared, or any permission requirements. Two-parameter tool with a complex nested data object warrants more disclosure.
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 extremely short (a single phrase), which is concise, but this is under-specification rather than efficient specification. There's room for more useful content without approaching verbosity - one or two sentences explaining update semantics and use case would be appropriate.
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?
This is a mutation tool with no annotations and no output schema. With a nested data object, partial-vs-full replacement ambiguity, and 50% schema coverage, the description is far too sparse to guide correct invocation. An agent needs to know update behavior, id semantics, and whether partial updates are supported - none of this is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% - two parameters (id, data) exist with only the id having description, and the data object's nested fields have descriptions but the 50% figure likely reflects the top-level. The description itself adds zero parameter information beyond what the schema provides, and doesn't explain the update semantics (e.g., partial vs full replacement of the data object).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'カスタムエントリを更新' (Update custom entry) states a verb+resource but is essentially a restatement of the tool name with no additional detail about what a custom entry is or how updating differs from related create/get/list operations. It doesn't distinguish from siblings like update_persona, update_career_entry, etc.
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 mention of when to use this tool versus alternatives. There are many update_X siblings, and without distinguishing context (e.g., what custom entries are used for, whether all fields are replaceable or partial), an agent can't decide when this applies versus other update tools or get_custom_entry.
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 fails to state that this is a mutation (updating a relationship entry), whether updates are partial/merge or full-replacement, whether is_private defaults to true (affecting visibility), or what fields are mutated. For a write operation with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It's maximally short (one phrase), which is technically concise, but this is under-specification rather than efficient conciseness. There are no wasted words, yet the brevity provides almost no information value beyond the tool's name itself.
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?
This is a mutation tool with a nested data object, 10 discrete fields, no output schema, and no annotations. The description should explain the purpose of the update operation, clarify field semantics, and discuss behavior. A single vague phrase is severely inadequate for a tool of this complexity. Compare with sibling delete_relationship/create_relationship which have similarly rich schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, meaning half the parameters lack descriptions. The description itself ('人間関係を更新') adds zero parameter context. The nested 'data' object with 10 fields, including type enum values (mentor/colleague/friend/family/partner) and is_private default, goes entirely undocumented in the description. Schema covers some fields well, but the description does nothing to compensate for the 50% gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '人間関係を更新' (Update human relationships) is nearly a tautology of the tool name. It states the verb+resource but adds no scope detail, no field specifics, and no distinction from sibling tools like update_persona or create_relationship. The schema reveals this is a partial-update tool for relationship entries with 10 updatable fields, but the description conveys none of that.
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 vs alternatives. It doesn't clarify that this is for updating an existing relationship (distinct from create_relationship for creating, or delete_relationship for removal). No mention of context such as requiring the entry to already exist, or that this is a partial update versus full replacement.
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 doesn't state whether creation is an insert, whether duplicates are prevented, whether certain dates must be validated, or what happens on partial failure. For a create operation with nested object structure, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse phrase '経歴を新規作成' - this is under-specification, not conciseness. There is no elaboration on the data model, required fields beyond the schema, or the distinction between period_year/period_start/period_end.
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?
This is a complex tool with a nested object, 16+ fields, no output schema, and no annotations. The single-sentence description is inadequate for an agent to understand the full data model, date field relationships (period_start/period_end/period_year), or validation between confidence/importance ranges.
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 50% description coverage - fields like role, tags, domain, summary, insights, metadata, org_type, confidence, importance, period_end, mentionable, period_year, mention_tone, organization, period_start all have inline descriptions. The description adds nothing beyond the schema, but the schema itself is reasonably self-documenting. A score of 3 reflects the baseline with moderate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '経歴を新規作成' (Create new career history) states the verb+resource clearly, but it's overly terse and doesn't distinguish from siblings like create_custom_entry, create_project, or create_education which follow the same create pattern. Without English or detail, the agent can only infer it creates a career/experience record.
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 vs alternatives like create_custom_entry or update_career_entry. There's no mention of prerequisites, validation rules, or conditions under which this tool is appropriate versus other creation 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 of behavioral disclosure. The description says nothing about what happens on creation (e.g., whether is_private defaults matter, whether real_name is stored differently, implicit visibility behavior). The schema shows an is_private default of true, but the description doesn't clarify side effects or behavioral traits of creation.
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 extremely short (six words in Japanese) and provides no structure. While brevity is generally good, this is under-specification rather than concise - it omits all behavioral and usage context. A single phrase with no elaboration fails to earn conciseness credit because it conveys almost no information.
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 a nested object, 10 sub-properties, auth-scoping considerations via profile_id, and no output schema, the description should explain return values, behavior when profile_id is unset for account-scoped keys, and relationship semantics. None of this is addressed. The schema's is_private=true default is a notable behavior that isn't surfaced in prose. This is incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 50%. The nested data object has well-documented fields with descriptions for each (type enum values, confidence range 1-10, is_private default true). The top-level profile_id also has a useful description explaining auth-key scoping behavior. The description itself adds nothing beyond the schema, but the schema does moderate work. With 50% coverage and no parameter info in the description, this sits at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "人間関係を新規作成" translates to "Create new human relationship" - it states a verb (create) and a resource (relationship), which is clear on surface level. However, it provides no distinction from siblings like create_relation or create_persona, and no elaboration on what a 'relationship' entails in this domain. It's minimally clear but lacks differentiating detail.
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 usage guidance whatsoever. The description doesn't state when to use this tool, prerequisites (e.g., whether a profile must exist first), or how it differs from create_relation, update_relationship, or create_persona. The profile_id parameter's description hints at auth scoping but that's schema-level, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description does not reveal that this is a mutable operation, what happens to unspecified fields (preserved or reset), whether update requires an existing episode, authentication/permission requirements, or error behavior. For a mutation tool with zero annotations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one token phrase), which is concise but under-specified rather than efficiently worded. There is no wasted text, but the brevity reflects lack of substance rather than purposeful economy. A single-sentence description here is too sparse to add value.
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 mutation tool with a complex nested 'data' object (16 fields), no annotations, and no output schema, the description is inadequate. It doesn't explain update semantics (partial vs merge), the STAR framework context implied by fields like situation/task/action/result, or consequences of updating. The description fails to convey essential usage information that neither schema nor annotations supply.
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 50%, with the 'data' nested object containing 16 fields each having brief descriptions. The description adds nothing beyond what the schema already documents. The nested 'data' object is a complex structure without guidance on partial vs full update semantics, and the description doesn't compensate for the 50% coverage gap or clarify how id and data interact.
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 episode) states a verb+resource clearly. However, it's a near-verbatim restatement of the tool name 'update_episode', adding minimal new meaning. It doesn't clarify what an episode is or distinguish it from the many sibling CRUD tools beyond the name itself.
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. There is no mention of whether this is a partial update (PATCH semantics) or full replacement, when episodes should be created vs updated, or any prerequisites for updating an episode. The sibling list has many similar update_* tools but no differentiation is offered.
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. 'スキルを更新' is only a single verb phrase with no information about mutation semantics, required permissions, irreversibility, partial vs full updates, or response behavior. For a mutation tool with zero annotation coverage, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal (one phrase), but this is under-specification rather than efficient conciseness. A single tautological phrase does not earn a high conciseness score because it fails to convey substantive content. The brevity costs clarity rather than enhancing it.
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 mutation tool with nested objects, no output schema, and no annotations, the description is inadequate. It should explain update behavior (partial vs full replacement, unknown-field handling given additionalProperties:false), what the response contains, and confirmation semantics. The complexity of the nested data object (9 sub-fields) with only 50% schema coverage means the description should compensate but 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?
Schema coverage is 50%: the nested 'data' object has well-described fields (name, tags, category, confidence ranges, etc.) in the schema itself. However, the top-level 'id' parameter is described only as 'エントリID (UUID)', and the description contributes nothing beyond the schema. The category enum values are listed, which is helpful, but the description adds no semantic context over what schema properties already provide. Baseline 3 for 50% coverage is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'スキルを更新' (update skill) is essentially a tautology—it restates the tool name in Japanese without adding any specificity about what aspect of skills is updated, how updates behave (partial vs full replacement), or what the result is. Among siblings (create_skill, get_skill, list_skills, delete_skill), the purpose is clear enough as 'update,' but the description adds zero detail beyond the name itself.
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. It doesn't clarify whether this is for partial field updates, whether id must already exist, whether creating vs updating is distinguished (e.g., upsert behavior), or mention any prerequisites. The sibling context implies an update operation, but there's no explicit when/when-not guidance.
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. 'Delete' implies a destructive/mutating operation, but the description doesn't state whether deletion is permanent, whether it affects related data (e.g., tags, relations), or requires special authorization. For a destructive tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), but this is under-specification rather than conciseness. However, given that there's only a single parameter fully documented in the schema, minimal extra content is strictly required. The brevity doesn't waste words but also doesn't earn credit for efficiency since it contributes so little.
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 annotations and no output schema, the description could (and should) disclose more. It should clarify whether deletion is permanent, whether related data is cleaned up, and what success/failure looks like. A single-phrase description that merely restates the tool name is inadequate given the tool's mutating nature.
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 a single parameter 'id' documented as 'エントリID (UUID)'. The description itself adds no parameter information beyond the schema. Per the baseline rule, with full schema coverage a 3 is appropriate since the schema already handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '実績を削除' (Delete achievement) is essentially a tautology of the tool name 'delete_achievement'. It states the verb+resource but adds no scoping information about what specific achievement entry is being deleted or how it relates to siblings like delete_goal or delete_project. It does minimally distinguish from sibling tools by naming the resource type, but offers nothing beyond the name itself.
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 usage guidance is provided. There's no mention of when to use this tool, prerequisites, or implications of deletion. The description doesn't clarify whether this is irreversible, whether it cascades to related entries, or when one might prefer this over sibling delete operations. An agent gets zero context about appropriate invocation 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 carries the full burden of behavioral disclosure for a destructive operation. The description simply says 'delete' without stating whether deletion is permanent, cascades to related records (e.g., tags, relations), or requires confirmation. There are no annotations to fall back on, making this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single phrase), which is technically concise, but this under-specification borders on being a tautology rather than intentional brevity. There are no wasted sentences, but the brevity comes from lack of elaboration rather than efficient communication.
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 tool with no annotations and no output schema, the description is too thin. It doesn't explain return behavior, idempotency (does deleting a non-existent ID error or succeed?), or any side effects such as cascading deletions to related tag/relation data. A deletion tool of moderate complexity visible among ~80 siblings needs more complete behavioral 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?
Schema description coverage is 100%, with the sole parameter 'id' documented as an entry ID (UUID). The description adds nothing about the parameter beyond what the schema states, so baseline 3 applies. With only one clearly-documented parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "経歴を削除" (Delete career) is minimal but does convey the action (delete) and resource (career). However, it's little more than a translation of the tool name itself and doesn't clarify what a 'career_entry' encompasses in this domain (e.g., employment history, work experience). It barely distinguishes from the many other delete_* siblings 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't address prerequisites (e.g., whether the entry must exist, whether related data is affected) or contrast with update_career_entry or other career tools. Context is entirely absent.
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 behavioral disclosure. 'Delete' implies data destruction, but it doesn't state whether deletion is permanent, cascading, requires auth, or affects related entities (like tags or relations that might reference the episode). This is a meaningful gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one word for the action plus object, effectively a single sentence). It's minimal but not wasteful; however, it borders on under-specification rather than genuine conciseness. It's efficient but lacks substance.
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 delete operation with no annotations and no output schema, the description is too thin. It doesn't explain return behavior, permanence, error conditions (e.g., deleting non-existent IDs), or relationship to the many sibling episode tools (create_episode, get_episode, update_episode, list_episodes). A single-tool description should provide more context given the bare-bones annotation coverage.
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 the single 'id' parameter described as 'エントリID (UUID)'. The description adds nothing beyond the schema, but with full coverage and only one well-documented param, the schema already carries the burden adequately. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'エピソードを削除' (Delete episode) adequately states the verb+resource (delete + episode), which is a minimal clear purpose. However, it doesn't distinguish from sibling delete tools beyond the resource name, and there's ambiguity about whether this deletes the episode or just its association — it does at least name the operation clearly.
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 delete_episode vs. alternatives. There's no mention of prerequisites (e.g., whether the episode must exist, whether deletion is permanent/reversible), nor references to related functions like update_episode or get_episode for verifying before/after deletion.
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. The description only states the action without disclosing behavioral traits: whether deletion is permanent, cascading (does it delete associated relationships/custom entries?), requires authentication, or is reversible. For a destructive operation with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at a single short phrase, but this veers into under-specification rather than effective conciseness. It is appropriately front-loaded but fails to earn its value by adding anything beyond the tool name itself.
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?
This is a destructive operation with no annotations and no output schema. The description should explain deletion semantics, permanence, cascading effects on related data (relationships, custom entries, tags), and any prerequisites. With only 'delete persona' stated, the description is inadequate for an agent to safely use this tool. The single ambiguous 'entry ID' parameter adds to the incompleteness.
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% coverage with a single 'id' parameter described as 'エントリID (UUID)' (entry ID, UUID). The description adds no parameter-level information beyond the schema, but since coverage is complete, the baseline of 3 is appropriate. The lack of context about what kind of entry ID this is (persona-specific, or general entry ID) is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ペルソナを削除' (Delete persona) states the core action of deleting a persona, but it is essentially a restatement of the tool name 'delete_persona'. It provides no additional clarity about what a persona is, what deletion implies, or what distinguishes this from related tools like delete_profile, delete_custom_entry, or delete_values_philosophy.
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. While sibling tools like delete_goal, delete_skill, and other delete_* tools suggest a per-resource deletion pattern, the description gives no context about when personas should be deleted versus profiles, custom entries, or other related resources. 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?
No annotations are provided, so the description carries full behavioral burden. The description only states it fetches details but doesn't disclose return format, error behavior on nonexistent IDs, permission requirements, or any side effects. Since this is a read operation and no annotations exist, the description should clarify the read-only nature and response characteristics, which it fails to do.
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 extremely brief (one clause) and is not verbose, but it's also under-specified relative to what an agent needs. It's concise but borders on truncated — no sentence about purpose context, return value, or relationship to list operations. Conciseness scores lower when brevity comes at the cost of 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?
This is a single-parameter read tool with no output schema and no annotations, so relative simplicity exists. However, the description fails to add context around what NFT listing details are returned, how this relates to list_nft_listings, or what constitutes valid listing_id input. For a tool with no annotations and no output schema, the description should carry more weight than it does.
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% — the single parameter listing_id is documented as '出品ID' (listing ID). The description adds the dimension that this ID refers to an NFT listing but provides no format or provenance guidance (e.g., how to obtain it, whether it's a UUID). With full schema coverage, baseline 3 is appropriate; the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'NFT出品詳細 — 特定のNFT出品の詳細情報を取得' (NFT listing details — get details of a specific NFT listing). It identifies the verb ('取得'=get) and resource (NFT listing), but does not distinguish from the sibling tool list_nft_listings or describe what '詳細情報' (detailed info) includes. The purpose is clear but lacks specification of what constitutes the details or how it differs from list operations.
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 vs list_nft_listings or other list/get siblings. The tool does not state prerequisites, typical scenarios, or alternatives. For a fetch-by-ID tool, some context about requiring a listing_id obtained from list_nft_listings would be helpful but is absent.
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 behavioral disclosure. The description is essentially just 'Get goal list' with zero behavioral information - no mention that this is a read-only operation (though inherently implied), no pagination/performance caveats, no indication of what happens with profile_id requirements. The param descriptions in the schema carry most of the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one phrase), which is concise, but it's under-specified rather than efficiently complete. The schema's param descriptions are well-structured, but the main description says nothing meaningful beyond the tool name itself.
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 6 parameters (including pagination, filtering, sorting, and profile scoping), the description provides almost no context. There's no output schema to explain the return structure, and the description doesn't describe pagination defaults, filtering syntax, or how the filter object maps to goal columns. The profile_id behavior is well-documented in the schema, but nothing above it explains the tool's full behavior.
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% - every parameter has a Japanese description explaining its purpose (limit, filter, offset, order_by, order_desc, profile_id). The description itself adds no parameter info beyond the schema. The profile_id param has notably good documentation about the API key scoping behavior. With 100% coverage, the schema already does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '目標一覧を取得' (Get goal list) identifies the verb (取得/get) and resource (目標/goals), but it's extremely terse. It doesn't distinguish from sibling tools like list_custom_entries, list_personas etc., though the resource name in the tool name provides the main differentiation. It adds minimal value beyond the tool name itself.
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 alternatives. Parameters hint at pagination and filtering capabilities, but the description gives no context about when this should be used over list_custom_entries or other listing tools, nor about profile-scoped vs account-scoped API key behavior (which is buried in a param description, not usage guidance).
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 were provided, so the description carries the full burden of behavioral disclosure. It's a read/list operation, but the description doesn't state whether it's read-only, what pagination behavior exists beyond the schema defaults, or what the returned structure looks like. For a list tool with no annotations, this is inadequate.
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 extremely concise (one short sentence), which is efficient, but it's under-specified rather than genuinely concise. There's no wasted text, but the brevity borders on under-specification given the tool complexity (6 params, nested filter object).
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 6 parameters including a nested filter object, but no output schema. The description doesn't explain the pagination/filtering capabilities partially documented in the schema, nor does it describe what relationship data looks like when returned. With no output schema and a complex filter mechanism, the description should do more to convey what the tool returns and how filtering works. The profile_id parameter has important API-key scoping behavior documented in the schema but not reflected in the description.
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. All 6 parameters (limit, filter, offset, order_by, order_desc, profile_id) have descriptions in the schema. The description itself adds nothing about parameters, but with full coverage, the schema handles the burden adequately. The filter param's 'column name: value' format is somewhat ambiguous but documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is '人間関係一覧を取得' (retrieve list of relationships), which states verb+resource but is minimal. It doesn't distinguish from sibling tools like get_relationship (singular fetch) or describe what a relationship entry contains. There's no detail to differentiate it clearly beyond the trivial verb+object.
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 vs alternatives. It doesn't mention that get_relationship fetches a single item, or how this compares to other list_* sibling tools. No exclusions, prerequisites, or context given.
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 disclosure burden. It fails to disclose whether this is a partial merge or full replacement, whether unknown fields are ignored or rejected, whether the operation is idempotent, or what happens to unspecified fields in the data object. For a mutating tool, this is a critical gap.
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 phrase, which is concise, but this is under-specification rather than genuine conciseness. No structure is provided (no sub-points, no caveats, no examples). It earns no credit for clarity since the minimalism comes at the cost of useful information.
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?
This is a nested-object mutation tool with no annotations and no output schema. Given the complexity (nested data object with 10 fields, partial-update semantics), the description should explain what fields are updatable, whether data is a full replace or merge, and typical use. It does none of this, making it inadequate for reliable agent 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?
Schema description coverage is only 50%, meaning half the parameters lack descriptions in the schema. However, the schema itself documents all data sub-fields (url, name, tags, type, year, detail, issuer, metadata, confidence, importance) reasonably well. The description adds nothing beyond the schema, so it doesn't compensate for the 50% coverage gap. The 'data' object's partial-by-omission semantics are unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '実績を更新' (update achievement) is essentially a tautology of the tool name. It does not specify what an achievement is, what fields are affected, or how this differs from create_achievement/delete_achievement/get_achievement siblings. The resource (achievement) is clear from the name alone, but no additional specificity is added.
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 create_achievement or other update_* siblings. The description provides no context about prerequisites (e.g., must the entry already exist?), partial vs full updates, or when updating is preferable to recreation. Usage must be inferred entirely from the tool name patterns.
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 state whether the operation is destructive/overwriting, whether unspecified fields are preserved or reset, whether the update is partial or full replacement, or any permissions/auth requirements. For a mutation tool with zero annotation coverage, this is a significant omission.
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 extremely short (a single fragment), which technically is concise, but under-specification should not be rewarded as conciseness. A short but uninformative description earns a neutral-to-low score. There is no front-loading of key information or structured content—just a single vague phrase.
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?
This is a mutation tool with no annotations, no output schema, and a nested 'data' object with many optional fields. The single-phrase description does not cover the return value, partial vs full update semantics, which fields are mutually exclusive (e.g., type enum values), or validation behaviors. For a tool with this complexity and coverage gaps, the description is inadequate.
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 50%, and the description adds zero parameter-level information. However, each parameter inside the nested 'data' object has its own description (tags, type, field, degree, etc.). The id parameter is described as 'エントリID (UUID)' and data as an object type. The description adds nothing beyond schema, but the schema itself documents parameters reasonably, so a baseline-adjacent score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '学歴・教育を更新' (update education/educational background) is largely a translation of the tool name. It restates the name without specifying what operation is performed, what resources are affected, or how it differs from related tools like create_education or delete_education. The verb '更新' (update) plus 'education' adds minimal information beyond the name itself.
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 create_education (for new entries) or update_career_entry/update_skill for other profile types. No context about when an education record should be modified, what valid states exist, or prerequisites (e.g., must the entry already exist, must an ID be obtained first via list_education/get_education).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description "目標を更新" reveals none of the behavioral traits — whether the update is partial (PATCH-like) or full replacement, whether it validates enum values in 'type', 'status', or constrained ranges in progress/confidence/importance, what happens on failure, or what the response looks like. With zero accompanying annotations, this is a critical 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?
At a single phrase (4 characters in Japanese), the description is maximally terse, which could be seen as concise. However, under-specification is not conciseness — it is a single phrasing with no elaboration of behavior, usage constraints, or anything the agent needs to know beyond the tool's basic name/resource identity.
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 schema documenting nested structures (milestones with {title, done, date}, metadata arbitrary object), the description does nothing to clarify semantics beyond raw field names. With no output schema and no annotation context, the description leaves the agent guessing about update semantics (partial vs. full replacement), return values, and error conditions. For a 2-parameter mutation tool with nested objects, 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?
Schema description coverage is 50% (the two top-level params id and data have descriptions, and nested fields are described). The description itself adds no parameter information, leaving the schema to carry the burden. Under the baseline rule, with 50% coverage, the description falls between needing to compensate and being redundant. It adds no semantics beyond the schema.
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 goal) expresses a clear verb+resource intent. It distinguishes itself from siblings like create_goal and delete_goal since "更新" means update. However, it doesn't elaborate on scope—what fields or aspects of the goal can be updated—so it relies entirely on the input schema for detail.
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 offers no guidance on when to use this tool versus alternatives. With siblings like update_episode, update_project, and update_achievement, there is no indication of what distinguishes a 'goal' update or what conditions apply (e.g., can completed goals be updated? are there conflicts with deleting vs. updating?). No when/when-not guidance is present.
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 behavioral disclosure burden. '健康エントリを新規作成' gives no information about side effects, whether entries are private by default (though the schema mentions is_private defaulting to true), retention, or data relationships. The description provides zero behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence which is efficient, but it's under-specified rather than appropriately concise. For a tool with nested objects and multiple parameters, the brevity borders on insufficiency rather than demonstrating careful trimming of unnecessary content.
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?
This is a complex create operation with a nested data object, multiple optional fields (tags, confidence, importance, is_private, metadata), a scoped profile_id parameter, and no output schema. Yet the description provides essentially no context about what the tool does beyond the name-translation. Someone new to the API would not know what distinguishes a health entry from other entry types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds no parameter meaning at all beyond what the schema already provides. The schema has nested object parameters (data with type/title/enum-ish fields) that need contextual explanation, especially the type field with its implied enum values (habit/condition/goal/routine) and the relationship between profile_id and scoping, but the description does not compensate for these gaps.
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 '健康エントリを新規作成' means 'Create new health entry' - it states the verb (create) and resource (health entry) clearly. However, it doesn't distinguish from sibling tools like create_life_event, create_goal, create_episode which may have overlapping semantics, and doesn't explain what a 'health entry' constitutes in this domain.
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 vs alternatives. The sibling list includes many creation tools (create_goal, create_episode, create_life_event) with potentially overlapping use cases, but the description provides no differentiation. There's no mention of prerequisites or when one might prefer a different tool, such as create_life_event for health-related life events.
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. As a create/mutation tool, it should disclose whether this is a write operation requiring specific permissions, whether events are associated with a profile, or any side effects. The description provides none of this. It doesn't even mention that a profile_id may be needed for certain API key types, which is relevant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one clause), which is efficient but crosses from conciseness into under-specification. There is no waste, but there's also virtually no informative content—the description adds nothing meaningful beyond the tool name itself.
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 a nested data object containing 10 fields and 2 top-level parameters, a single-sentence description is inadequate. There's no output schema and no annotations, so the description needs to compensate but doesn't. The complex type enum, date format, and auth requirements for profile_id are all undocumented in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description must compensate, but it provides zero information about the data structure. The nested 'data' object has 10 properties (type, title, tags, impact, metadata, confidence, event_date, importance, description) and the description explains none of them. The important enum-like constraint on 'type' (turning_point/relocation/major_change/milestone) is only in the schema, not the description. profile_id's special auth behavior is entirely undocumented in the description.
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 'ライフイベントを新規作成' (create a new life event) uses a specific verb+resource, clearly indicating this creates a life event. However, it doesn't add meaning beyond what the tool name 'create_life_event' already conveys, and it doesn't distinguish from siblings like create_profile, create_persona, etc. The translation makes the purpose obvious though not enriched.
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. The sibling list contains many create_* tools (create_persona, create_episode, create_goal, etc.), and the description offers no differentiation or selection criteria. It doesn't explain when a 'life event' is the right entity to create versus other resource types.
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. The description simply says 'create new skill' with no mention of mutation behavior, uniqueness constraints on skill names, whether creation requires an existing profile, what happens on duplicate names, or what the response contains. For a write operation with zero annotation coverage, this is an inadequate disclosure.
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. It's appropriately brief, though perhaps too brief given the tool's complexity. As written it is concise, but it sacrifices informational value for brevity.
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?
This is a complex nested-object tool with 9 child properties in the data object, 0 annotations, no output schema, and only 50% schema coverage on the top-level. The description does nothing to explain return values, error conditions, uniqueness expectations, or the relationship between create_skill and its update/get/list siblings. Given the tool's complexity, a two-word description is clearly 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?
Schema description coverage is 50%. The schema itself documents most parameters well (name, category, tags, evidence, metadata, confidence, importance, proficiency, years_experience all have descriptions in Japanese). The profile_id parameter is well-documented in the schema including scoping rules. The description adds no parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'スキルを新規作成' (create new skill) states the verb and resource clearly enough, so the core purpose is understandable. However, it does not distinguish from sibling tools like create_career_entry, create_achievement, create_project, etc., which follow the same create_X pattern. There is no additional scope or contextual detail beyond the tautological name reuse.
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 when-to-use guidance is provided. It doesn't explain when creating a skill is appropriate versus updating an existing one (update_skill exists as a sibling), nor does it mention any prerequisites or profile binding requirements that exist in the schema (profile_id handling). Usage context must be inferred entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' implies destructive action, but the description doesn't state whether the deletion is irreversible, whether it requires special permissions, whether associated data (skills, career entries, etc.) is affected, or what the response looks like. For an irreversible mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one short phrase, which earns points for brevity. However, this borders on under-specification rather than genuine conciseness - the description is so minimal that it reads like a tautology of the tool name rather than a deliberate, information-dense summary. There's no structure or elaboration that helps an agent make decisions.
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 that delete_profile operates on a major resource type (profile) in an ecosystem with dozens of related entry types (skills, projects, achievements, career entries), the description is woefully incomplete. It doesn't explain what a profile is, whether deleting it cascades to sub-entries, or whether there are constraints (e.g., cannot delete the primary profile). No output schema exists to describe return values, compounding the gap.
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 has only 1 parameter (id, required) and 100% schema description coverage, with the description already stating it's an entry ID (UUID). The baseline of 3 applies here due to full schema coverage. The description itself adds nothing beyond the schema, but since the schema fully explains the single parameter, a 4 is reasonable - there's no parameter meaning gap to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'プロフィールを削除' (Delete profile) states a verb + resource clearly enough, making the basic purpose understandable. However, it's essentially a restatement of the tool name 'delete_profile' and provides no detail about scope, what gets deleted (only the profile itself or associated entries like career, skills, projects?), or side effects, which is critical for a destructive operation.
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 vs alternatives. With many sibling deletion tools (delete_skill, delete_project, delete_episode, etc.) and related profile tools (create_profile, update_profile, list_profiles), there's no clarification about the relationship between profiles and these other resources, nor whether deletion cascades to dependent data. The context is the presence of a profile entry but no exclusions or alternatives are given.
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 for behavioral disclosure. The one-word description 'エントリの関連を取得' (get entry relations) tells the reader this is a read operation but nothing more—no pagination, sorting, response shape, or failure behavior. The parameter 'direction' implies filtering between incoming/outgoing/both, which is some behavioral context, but the description itself is nearly empty.
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 extremely short (8 characters of meaning), which is efficient but drastically underspecified. Conciseness alone isn't the issue; the problem is that nothing is explained. There is no wasted text, but there is also essentially no content to evaluate for structure.
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 3 parameters (one complex enum), 2 required params, no output schema, and no annotations—so the description must carry substantial explanatory weight. It clarifies which entities can have relations (entry_type enum suggests profiles, skills, projects, etc.) but doesn't explain what 'relations' means, how direction affects results, or what the return format is. For a read tool with zero annotation support, this is inadequate.
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 each parameter has a schema-level description (entry_id: 'エントリID', direction: '方向 (デフォルト: both)', entry_type: 'テーブル名'). The schema already documents parameters well, placing a baseline of 3. However, the description adds nothing beyond this—no clarification of the default parameter interactions or how entry_type maps to relation semantics. The 'direction' default of 'both' is helpful but is already in the schema.
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 'エントリの関連を取得' (get entry relations) uses a specific verb (取得/get) and a resource (relations), which is reasonably clear. However, it doesn't distinguish itself from sibling tools like create_relation or delete_relation beyond the verb, and it doesn't clarify what kind of relations (inter-entry links for the persona graph). It's functional but minimal.
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 about when to use this tool versus alternatives. The sibling set includes create_relation and delete_relation, and the description gives no hint about when to use get_relations versus other retrieval tools like get_profile or get_skill. No exclusions, alternatives, or context 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 carries full burden for behavioral disclosure. It does not state whether the operation is read-only, whether it requires authentication, whether results are paginated, what the return format is, or any ordering/limits. '取得' implies reading but no behavioral traits are disclosed beyond that.
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 extremely short ('タグ一覧を取得'), which is concise, but it borders on being a tautology of the tool name. It's under-specification rather than efficient conciseness - a single phrase that provides minimal value beyond the name itself.
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 list tool with one optional parameter, no output schema, and no annotations, the description should at least indicate what the list operation returns, whether ordering exists, and any relationship to category filtering. None of this is present. The tool is simple but the description still falls short of adequately preparing an agent to use it.
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% - the single parameter 'category' is documented as 'カテゴリでフィルタ' (filter by category). The description doesn't add parameter semantics beyond the schema, but the schema already fully covers the parameter, so baseline 3 is appropriate.
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?
Description "タグ一覧を取得" (Get tag list) clearly states the verb (取得/get) and resource (タグ一覧/tag list), matching the tool name list_tags. It's clear but minimal; among siblings there are list_* tools like list_hobbies, list_skills, so it distinguishes the resource type adequately but provides no additional scoping or detail beyond the name itself.
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 vs alternatives. There's no mention of related tag operations (create_tag, tag_entry, untag_entry, get_entry_tags) or when listing tags would be appropriate vs filtering by category. The description provides no usage context at all beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description provides zero transparency about side effects (mutation semantics), partial-update behavior, required id existence, reversibility, or response format. For a mutation tool with zero annotations, this is a critical gap.
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 extremely short (one phrase), which is concise, but it's under-specification rather than efficient writing. It's minimal waste, but a one-phrase description doesn't provide enough value for a 2-param tool with a nested object and no annotations. It's terse, not necessarily well-structured.
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 a nested 'data' object with 8 subfields, no annotations, and no output schema, the description should clarify update semantics (merge vs replace), whether related_skills/tags replace or append, and what happens on missing id. None of this is provided. The schema documents the data shape but not the update behavior, which is the key missing context for an update tool.
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?
With 50% schema description coverage, the description adds nothing about parameters, but the input schema itself is quite thorough (describes id as UUID, describes all nested data fields including name, tags, confidence, etc.). The data object's semantics as a partial vs full replacement is not clarified, but the schema does most of the heavy lifting for parameter meaning.
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 hobby) states the verb (update) and resource (hobby), conveying the basic purpose. It distinguishes from siblings like get_hobby, list_hobbies, and delete_hobby, but it's minimal and its clarity relies on the tool name itself. A slightly more descriptive purpose would earn a 4.
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 alternatives. Notably, there's a create_hobby sibling and other update_* tools, but the description gives no context about partial vs full updates, whether the 'data' object replaces the entire entry or merges, or any exclusions. The implied usage (call when you need to modify a hobby) is evident but nothing more.
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. A create operation implies mutation, but the description doesn't state whether this requires specific permissions, whether created entries are immediately visible, whether there are any side effects, or what the response/return value looks like. The profile_id behavior for account-scoped keys is a notable behavioral detail embedded only in the schema, not the description.
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, which is concise but borders on under-specification. Being brief is not inherently bad, but the description is so minimal that it doesn't provide meaningful guidance. There's no wasted text, but there's also very little earned substance.
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 create operation with 2 parameters including a nested object with 10 sub-fields defining types (certification, membership, board_member, award, talk, patent), no output schema, and no annotations, the description does remarkably little. It doesn't explain the type taxonomy, the profile_id scoping rules, or what happens on success. The complexity of the data structure is left entirely to 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?
Schema description coverage is 50%, which is moderate. The schema itself documents each field (name, type, url, tags, year, etc.) with Japanese descriptions, and the type enum values are documented. The description adds nothing beyond what the schema provides, so it neither helps nor hurts. The nested 'data' object structure is only apparent in the schema.
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 "実績を新規作成" (Create new achievement) states the verb and resource clearly, so the agent knows this creates an achievement record. However, it's extremely minimal and doesn't distinguish from siblings beyond the obvious create operation, nor does it describe what an achievement encompasses (certifications, memberships, awards, talks, patents per the type field).
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 alternatives. It doesn't mention the profile_id requirement nuance (account-scoped keys need it, profile-scoped keys default to bound profile), which is a significant usage consideration. There's no mention of when creating an achievement is appropriate vs. other entity creation 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 (no readOnlyHint, destructiveHint), so the description carries the full burden of behavioral disclosure. The description says only 'create new episode' — it does not disclose that this is a mutation, whether it requires authentication/profile binding, whether it appends to a profile's collection, or what validation occurs on the type enum values. For a write operation with zero annotations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence in Japanese, which is appropriately brief. But it's arguably under-specified rather than concise — the single phrase 'create new episode' provides minimal value and could have been expanded to cover the STAR structure and data model without becoming verbose. It's efficient but under-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?
This is a moderately complex tool: nested objects, 15+ fields, a type enum, profile-scoped vs account-scoped key handling, and no output schema. Given this complexity and no annotations, the one-sentence description is inadequate. It doesn't explain the episode data model (STAR framework), the type taxonomy, how episodes relate to profiles, or how success/failure validation might work. Compared to sibling tools like create_achievement or create_life_event, the description fails to position this tool within the broader domain.
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 50% description coverage. The description itself provides zero parameter information. However, the schema descriptions are reasonably rich in Japanese (e.g., type enum values, STAR field labels, confidence/importance ranges). The description doesn't add anything beyond the schema, and the profile_id guidance about key scoping is already in the schema. There's a partial gap for the ~50% of fields lacking schema descriptions (mention_tone, metadata, period fields have short/absent descriptions).
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 'エピソードを新規作成' (create new episode) clearly states the verb+resource action. However, it doesn't clarify what an 'episode' is in this context (STAR framework, career/professional narrative entries), nor does it distinguish from sibling tools like update_episode or delete_episode beyond the obvious create/update/delete distinction. The schema reveals STAR fields (situation/task/action/result), so a hint about this structure would add value.
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. There are many sibling create_* tools (create_skill, create_project, create_achievement, create_career_entry, etc.), and the description gives no differentiation between what constitutes an 'episode' versus a 'life_event', 'career_entry', or 'achievement'. The schema's profile_id description offers some context on key scoping, but that's structured data, not usage guidance.
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 simply states 'create new persona' without disclosing whether this is destructive, what side effects occur (e.g., does it modify the profile?), what the idempotency behavior is, or what the response returns. For a complex tool with 14 parameters including nested objects, this is a significant behavioral gap.
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, which is concise. However, it borders on under-specification—only 6 characters effectively ('create new persona') with no additional context. It's not verbose waste, but it's too minimal to be judged as well-structured or 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?
This tool has a complex nested data object with 14 sub-parameters, a required profile_id dependency (with nuance about account-scoped vs profile-scoped keys), and no output schema. For this complexity, a single sentence is inadequate. The profile_id description in the schema provides useful context, but the tool description itself fails to mention the profile-scoping dependency, required fields, or behavioral expectations.
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 50%, and the description adds zero parameter information beyond what the schema provides. However, the schema itself is quite rich with descriptions for most parameters (tone, language, confidence ranges, entity_weights examples). The description adds nothing, so it cannot compensate for the 50% coverage gap, but the baseline 3 applies since the schema does heavy lifting.
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 'ペルソナを新規作成' (create new persona) uses a specific verb+resource, clearly indicating it creates a persona. It distinguishes from siblings like update_persona and delete_persona, but is very brief and doesn't add detail about what a persona represents or how it differs from get/list personas.
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. With dozens of create_* siblings and a complex persona concept, there's no context about when persona creation is appropriate, its relationship to profiles, or how it differs from other creation tools. The profile_id parameter hints at a dependency but this isn't explained in the description.
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 for behavioral disclosure. It does not state what happens when values are created (e.g., whether they're linked to a profile, whether duplicates are rejected, whether it overwrites existing data), what the response contains, or whether specific scoping/permissions are required. For a mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one short phrase), which is concise, but it borders on insufficiency rather than intentional conciseness. While there is no wasted text, the brevity itself is a limitation for a tool with nested objects and multiple nuanced parameters.
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?
This is a create (mutation) tool with a nested data object containing 8 fields, no annotations, and no output schema. The description is a single phrase that conveys only 'create values/philosophy.' It does not explain the type taxonomy, the meaning of the various numeric/string fields, profile scoping rules, or what the tool returns — particularly inadequate given the nested structure requires careful handling.
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 50%, so the schema documents some parameters. The description adds nothing beyond 'create' — it doesn't explain the distinction between type values (value/philosophy/belief/principle), the meaning of origin, confidence, or importance fields, or the relationship between data and profile_id. The type field's enumerated-like values and the profile_id binding behavior are documented only in the schema, and the description doesn't reinforce or elaborate on them.
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 '価値観・哲学を新規作成' means 'Create new values/philosophy' which clearly indicates the verb (create) and resource (values/philosophy). However, it doesn't differentiate from sibling tools like create_persona, create_skill, etc., within the broader profile domain. It identifies the resource but lacks scoping detail about whether it's tied to a profile.
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 alternatives. There are many create_* sibling tools, and the description doesn't explain when values/philosophy should be recorded here versus in create_persona or create_custom_entry. No exclusions or alternatives mentioned. The description provides no context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description simply states the deletion action without disclosing whether deletion is permanent, whether it cascades to related resources (e.g., entries, tags, relationships), whether confirmation is required, or access/auth requirements. For a destructive operation with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short single phrase with no wasted words, but it is under-specified rather than concisely complete. Conciseness at this minimal level doesn't earn a higher score because it sacrifices crucial information about the tool's behavior.
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 tool with no annotations, no output schema, and a single parameter, the description should disclose permanence, effect on related data, and success/failure behavior. The one-line Japanese description fails to provide this essential context, making it inadequate for an agent to safely invoke a delete 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 description coverage is 100% - the only parameter (id) is documented in the schema as "エントリID (UUID)". The description adds nothing beyond what the schema already provides, so baseline 3 is appropriate. No additional meaning or context about the id parameter is given in the description.
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 "プロジェクトを削除" (Delete a project) conveys a clear verb+resource purpose. However, it's a minimal Japanese phrase that doesn't add differentiation beyond what the tool name already implies, and with many sibling delete_* tools it doesn't clarify what distinguishes deleting a project from deleting other resources.
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. There's no mention of prerequisites (e.g., whether the project must exist), cascading effects on related entries, or when to prefer delete_custom_entry or other deletion tools. The description gives no usage context whatsoever.
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. The description only states the retrieval action and ID specification but doesn't disclose what the tool returns, whether it errors on missing IDs, authentication requirements, or any side effects. For a read operation, this is a notable gap given 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), which is concise but borders on under-specification rather than efficient communication. It communicates purpose and the ID mechanism in a compact form, but there's no elaboration on context or behavior. It's efficient but minimal.
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 one parameter, no output schema, and no annotations, the description should compensate by explaining what a successful/failed lookup yields. The description covers the basic operation but provides no completeness regarding return format, error behavior, or relationship to sibling tools. For a simple retrieval tool this is adequate but lean.
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 the single parameter 'id' having a description 'エントリID (UUID)' (Entry ID (UUID)). The description adds no information beyond what the schema already provides. Baseline 3 is appropriate since the schema fully documents the parameter.
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 '目標を取得 (IDで指定)' translates to 'Get goal (specified by ID)'. It uses a clear verb+resource (get goal) but is minimal and doesn't differentiate from sibling tools like get_hobby, get_persona, etc., which all follow the same pattern. It does convey the basic purpose of retrieving a goal by ID.
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. While the ID-based retrieval pattern is implied, there's no mention of when to use get_goal versus list_goals (for listing) or update_goal (for modification). No exclusions or alternative suggestions 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 carries full behavioral burden. It adds essentially nothing beyond the tool name itself — no mention of return format, error behavior for missing IDs, authorization requirements, or any side effects. For a read operation with zero annotation coverage, this is a meaningful gap.
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, which is efficient, but it's under-specified rather than concisely informative. It's not wasteful, but it also doesn't earn its place by adding useful detail beyond the tool name and schema.
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 that's one of many near-identical get_* siblings (get_hobby, get_skill, get_persona, etc.) with no annotations and no output schema, the description should clarify what a 'relationship' entry is and how retrieval behaves. The Japanese locale note may also impede non-Japanese agents. The description is too thin to be 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% and there's only one parameter (id, UUID). The description's parenthetical '(IDで指定)' merely restates what the schema already documents. With full coverage and a single simple param, baseline 3 is appropriate — the description adds no additional semantic value.
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 '人間関係を取得 (IDで指定)' (Get relationship by ID) states a clear verb+resource, retrieving a relationship entry by ID. It distinguishes from the broader list_relationships sibling, though the parenthetical adds little since the schema's required `id` field already establishes this.
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 like list_relationships or get_relations. The description implies 'get by ID' but doesn't specify context (e.g., when you have a UUID from a list call). Among many near-identical get_* siblings, no differentiation is offered.
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 mentions none: no return format, no pagination behavior, no authentication requirements, no mention of what 'achievements' refers to, and no note about profile-scoped vs account-scoped behavior (though the profile_id parameter hints at this). A list operation with zero behavioral detail 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at one short sentence, which is technically concise. However, this borders on under-specification rather than genuine conciseness—the description is too sparse to earn a 4. It does front-load the purpose clearly, but offers no additional value beyond the tool 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?
For a list tool with 6 parameters including a nested filter object, 0 required params, no output schema, and no annotations, the description is incomplete. It doesn't explain the meaning of '実績' (achievements) in this domain, how filtering works with the nested object, or what the return structure looks like. The two-line description under-delivers 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 schema description coverage is 100%, with every parameter documented (limit, filter, offset, order_by, order_desc, profile_id each have Japanese descriptions). The description itself adds nothing beyond the schema, but per the baseline rule, with 100% coverage a 3 is appropriate. The schema does the heavy lifting here.
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 '実績一覧を取得' (get achievements list) clearly identifies the verb+resource action. However, it's very terse and doesn't distinguish this from other list_* siblings like list_hobbies, list_skills, or list_projects beyond the resource name in the tool name itself. The purpose is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. The description doesn't mention any context for use, such as retrieving a profile's achievements list or how it relates to get_achievement (single item retrieval) or create/update/delete siblings. A single non-explanatory sentence provides no contextual direction.
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 behavioral burden. It does not disclose whether this is a read-only operation (likely, but unstated), pagination behavior, default ordering behavior, or the response format. Since no output schema exists either, the agent has no indication of what to expect from the return value.
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 extremely short (single sentence). While concise, it may be underspecified given the parameter complexity (6 params, nested object filter). The brevity is not 'zero waste' since it misses important guidance; it's simply minimal.
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 6 parameters, a nested filter object, no output schema, and no annotations. The description provides no context on pagination, default values, filter syntax, order semantics, or the profile-scoping behavior that the schema mentions for profile_id. For a list endpoint with this complexity, the description is insufficiently 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 description coverage is 100%, so all 6 parameters are documented in the schema (limit, filter, offset, order_by, order_desc, profile_id). The description adds nothing beyond the schema. Per calibration rules, baseline 3 is appropriate since the schema does the heavy lifting for parameter documentation.
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 'カスタムカテゴリ一覧を取得' (retrieve list of custom categories) clearly states the verb (get) and resource (list of custom categories). However, it doesn't distinguish from siblings like get_custom_category, create_custom_category, update_custom_category, and delete_custom_category — though the list-vs-singular distinction is somewhat evident from the name itself, so the differentiation is implicit.
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 list_custom_entries or other list_* tools. No exclusions or alternative tool mentions. The presence of a filter parameter and pagination is implied but not explicitly stated as the intended use case.
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 doesn't mention pagination behavior, output format, whether results are profile-scoped, or any side effects. The description is too minimal to convey behavioral traits beyond 'this lists things'.
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 extremely concise—a single short phrase. While there is no wasted prose, this level of brevity crosses from 'concise' into 'under-specified'. The short length is appropriate for a tool with 100% schema coverage, but it omits context that could help an agent.
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?
This is a list tool with 6 parameters, 40+ sibling tools including many other list_* tools, no output schema, and no annotations. The description provides no usage context, no return-value expectation, and no distinction from similar list tools. For the complexity and modest schema richness, the description is insufficiently 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 description coverage is 100%, so all 6 parameters are documented in the schema with descriptions (limit default 50, offset, order_by, order_desc, profile_id, filter). The description itself adds no parameter context, but with full schema coverage, the baseline 3 is appropriate. The filter param has a somewhat ambiguous description ('カラム名: 値') but that's schema's responsibility.
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 'カスタムエントリ一覧を取得' (get custom entry list) states the verb+resource clearly. However, it doesn't distinguish from sibling tools like get_custom_entry (singular) or list_custom_categories, though the plural '一覧' (list) plus 'custom_entry' is fairly clear. It doesn't provide any detail about scoping or what custom entries represent.
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 alternatives. There's no comparison to get_custom_entry, list_custom_categories, or search. The description doesn't mention scenarios or limitations, so an agent must infer usage purely from the tool name and sibling 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states it retrieves a list, revealing nothing about output format, pagination behavior beyond what schema implies, potential error cases, permission requirements, or whether it's a read-only operation. For a read operation with zero annotation coverage, more transparency (e.g., result ordering, default behavior) is warranted.
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 concise sentence with zero waste. However, it is under-specified for a 6-parameter list tool with no annotations and no output schema. The conciseness is good, but it doesn't carry enough informational value to warrant higher than a 3; it's minimal rather than appropriately compact.
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?
This is a 6-parameter list-fetching tool with no annotations and no output schema. For a pagination-capable list operation (limit, offset, order_by, filter, profile_id), the description should explain what the list contains, default behaviors, or any call-order prerequisites. The single sentence leaves the tool's behavior largely inferred from schema fields rather than explicitly documented. Moderate complexity warrants more completeness.
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% (all 6 parameters are documented in the schema). The description itself adds no parameter-level meaning beyond what the schema already provides. The profile_id parameter's description in the schema already explains the account-scoped vs profile-scoped key nuance. Per the baseline rule (schema coverage >80%), a 3 is appropriate.
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 'ライフイベント一覧を取得' (Retrieve life events list) clearly indicates the verb (get/list) and resource (life events). However, it's a single short sentence with no contrast against siblings like list_career_entries, list_episodes, etc. Since this is a list operation among many list_X tools, the purpose is clear but lacks any differentiation or scoping detail beyond the name itself.
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 about when to use this tool vs alternatives. Sibling tools include get_life_event (singular), list_relationships, list_profiles, etc., but the description offers no when-to-use or when-not-to-use information. However, the parameter profile_id does mention account-scoped vs profile-scoped key behaviors, which provides indirect usage context. Still, no explicit alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states a mutation action (assigning tags) but does not disclose whether the operation is idempotent, whether re-tagging with the same name is handled gracefully, whether tag_category is used only on new tag creation, or what happens to existing tags. With zero annotation coverage, a mutation tool describing only its action without side effects or behaviors 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short sentence, which is efficient. However, it borders on under-specification rather than conciseness - it saves words but fails to deliver needed content about usage, behavior, or parameter semantics. A single terse sentence that omits all context is not well-balanced 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?
This is a mutation tool with no output schema, no annotations, and a simple but consequential operation (modifying entries by attaching tags). The schema covers parameters well, but the description fails to convey behavior around duplicate tags, category handling, or interaction with the untag_entry / list_tags siblings. For a tool that modifies data across 15 distinct entry types, the minimal description is inadequate.
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 schema documents all four parameters adequately. The description adds no parameter-level detail beyond what the schema already states. The tag_category parameter's role ('新規作成時' = when creating new) is documented in the schema but not elaborated in the description. Baseline 3 is appropriate given full schema coverage with no additional descriptive value.
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 'エントリにタグを付与' (assign tags to entries) states the verb+resource clearly but is terse. It does not distinguish itself from sibling tools like untag_entry, get_entry_tags, create_tag, or list_tags beyond the basic action. The purpose is clear but lacks the specificity to differentiate from related tag-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 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. There's no mention that tag_name auto-creates tags (though this is in the schema), no indication of relationship to create_tag or untag_entry, and no prerequisites stated. The description provides zero usage context for an agent to decide between this and sibling tag 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 of behavioral disclosure. The description only says 'update health entry' with no mention of what happens on update (partial vs full replacement), whether is_private defaults apply, data validation behavior, or any side effects. For a mutation tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 characters of substantive content); while there's no waste, this is under-specification rather than genuine conciseness. A single sentence with no additional context fails to leverage the space available for a tool with a nested object parameter.
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 nested objects, 2 required params, no output schema, and no annotations, the description provides almost nothing beyond the tool name. It doesn't explain the update semantics (partial update? merge vs replace?), default behaviors (is_private defaults to true per schema but unstated), or the response format. This is inadequate for an agent to use confidently.
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 50%, with the two required params (id, data) — the 'data' nested object contains many fields with descriptions. The overarching 'data' parameter itself has no description beyond being an object of updatable fields. The description adds no parameter-level meaning beyond what the schema provides, so with 50% coverage this is borderline adequate but could compensate more for the undocumented params.
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 health entry) states the verb (update) and resource (health entry), which is clear. However, it's minimal and doesn't differentiate from the many sibling update_* tools (update_skill, update_project, etc.) other than naming the resource, which is already obvious from the tool name itself.
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 vs alternatives. No mention of prerequisites (such as having an existing entry ID), no mention that create_health_entry should be used first, and no exclusions or alternative tool references. The usage context must be entirely inferred.
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. The description gives no hint about update semantics: whether it performs a partial merge or full replacement, whether missing fields are cleared, whether it requires the entry to pre-exist, or what the return value is. For a mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single sentence in Japanese. While concise, this borders on under-specification rather than effective brevity. It says nothing beyond the tool name 'update' + resource type, so it's not truly earning its place by adding information. It's efficient but lacks substance.
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?
This is a mutation tool with nested objects, 8 updatable fields, no annotations, and no output schema. The description does nothing to guide the agent on how to structure updates, what happens to unspecified fields, or return behavior. Given the schema richness (8 fields in data object), the description is inadequate to fully support correct 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?
Schema description coverage is 50%—fields like id, title, data are documented in the schema while others are covered too. The description contributes nothing about parameters. The data object and id are both described in the schema reasonably well, and with part of the coverage documented, a baseline 3 is appropriate. The type field's allowed values (value/philosophy/belief/principle) are documented in the schema.
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 values/philosophy) specifies the verb (update) and resource (values/philosophy), making the core purpose clear. However, it's a terse one-liner in Japanese that doesn't distinguish it from the sibling create_values_philosophy or get_values_philosophy beyond the verb, though 'update' does differentiate from those. It's functional but minimal.
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. No mention of prerequisites (e.g., must fetch existing entry first), no mention of partial vs full update semantics, and no reference to sibling tools like create_values_philosophy or delete_values_philosophy. The agent must infer usage entirely from the 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?
No annotations are provided, so the description carries the full burden. While '新規作成' (create) clearly implies a write/mutation operation, the description does not disclose whether profile_id is required, what happens on duplicate education entries, validation rules, or what the response/return value looks like. The schema hints at profile-scoped vs account-scoped key behavior, but the description doesn't surface this responsibility to the agent.
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?
Single short sentence with no waste. It's appropriately concise for what it conveys, though it's arguably under-specified rather than efficiently written. For a simple create tool, one sentence is acceptable.
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?
This is a create tool with a nested data object containing 10 properties, a required type field, and profile_id handling semantics (account-scoped vs profile-scoped keys). The description is a single terse sentence that doesn't explain the main data structure requirements, the type enum constraint, or the profile binding behavior. With no output schema and no annotations, the description should do more to orient 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 description coverage is 50% (half the schema properties have descriptions). The description adds nothing about parameters beyond what's in the schema. The schema already provides decent descriptions for most fields (type enum, confidence 1-10, importance 1-10, profile_id behavior). Since coverage is moderate (~50%), the description doesn't add value beyond the schema but doesn't need to fully compensate. Baseline 3 is appropriate.
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 '学歴・教育を新規作成' (create education/educational history) uses a clear verb (新規作成/create) and resource (学歴・教育/education). It's a create operation for education entries, matching sibling patterns like create_hobby, create_skill, create_project. However, it doesn't distinguish itself from other create_* tools beyond the resource name, which is somewhat self-evident from the tool name itself.
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. No mention of distinguishing from update_education, delete_education, or the related create_career_entry, or when education data should be created vs. career entries. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' clearly implies destructive action, but the description doesn't state whether it's reversible, whether it affects related entries (e.g., linked tags, relationships), or whether authorization/permissions are required. For a destructive tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words. However, it's arguably under-specified rather than concise—the brevity is achieved by omitting useful behavioral context rather than by efficiently conveying essential information.
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?
This is a destructive mutation tool with no annotations, no output schema, and only a single-id input. Given the tool's simplicity, a one-line description might suffice, but for a delete operation the lack of any warning about irreversibility or cascading effects is a notable omission. Adequate but minimal.
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 a single 'id' parameter documented as 'エントリID (UUID)'. The description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate since the schema fully documents the sole parameter.
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 '学歴・教育を削除' (delete education) states a clear verb (delete) and resource (education), which establishes the core purpose. However, it doesn't distinguish from siblings—though the sibling list has many 'delete_*' tools, they target different resources so confusion is minimal. It's clear but minimal, providing no additional scoping or context.
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 vs alternatives is provided. There's an obvious related tool 'update_education' and 'create_education', but the description doesn't clarify when deletion is appropriate or mention any cascading effects on related data. The agent must infer usage purely from the name.
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. The description only states the action ('delete') with no details on irreversibility, what happens to related data, or any side effects. This is a bare minimum disclosure for a mutating operation.
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 zero waste, which is appropriately concise for a tool with one parameter. However, it errs on the side of under-specification rather than genuine 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 mutation tool with no annotations, no output schema, and a single-parameter input, the description should provide more context about the deletion behavior, irreversibility, or relationship to other health entry operations. The two-word description is inadequate for a delete 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?
With 1 parameter at 100% schema description coverage, the schema already documents the 'id' parameter as 'エントリID (UUID)'. The description adds no additional meaning beyond the schema, which puts this at the baseline of 3 for good schema coverage.
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 '健康エントリを削除' (delete health entry) states the verb (delete) and resource (health entry), making the basic purpose clear. However, it does not distinguish itself from the many sibling delete tools like delete_hobby, delete_career_entry, etc. beyond the resource name itself.
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 update_health_entry, delete_custom_entry, or other delete tools. There is no context about prerequisites, such as needing an existing entry or undelete behavior.
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. A delete operation is inherently destructive, but the description doesn't specify whether deletion is permanent, whether relations or tags associated with the event are also removed, or whether the operation can be undone. This is a meaningful gap for a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It is appropriately terse for a tool whose semantics are largely captured by its name and schema. However, the extreme brevity leaves out behavioral nuance that could have been included without bloat.
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 single-parameter destructive operation with no annotations and no output schema, the description relies entirely on the name for context. It fails to disclose whether this is a permanent/irreversible action, whether it affects related entities (tags, relations, custom entries), or any required permissions. Given the destructive nature, this is insufficiently contextualized.
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 the single id parameter documented as 'エントリID (UUID)'. The description adds no parameter information beyond what the schema already provides. With full schema coverage, baseline 3 applies. The description does not clarify what entity type the UUID refers to, but this is reasonably implied by the life event context.
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 "ライフイベントを削除" (Delete life event) states a clear verb+resource: deletion of a life event. It distinguishes from siblings like update_life_event and list_life_events, but among the many delete_* tools (delete_hobby, delete_custom_entry, etc.) it doesn't add differentiating detail about what a life event specifically is.
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 alternatives. It doesn't mention prerequisites or exclusions (e.g., whether deleting a life event cascades to related entries, whether it's destructive in a way requiring confirmation). No when-to-use or when-not-to-use context is 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 carries the full burden of behavioral disclosure. It does not state whether deletion is irreversible, whether it cascades to other entities, requires authentication/permissions, or what happens on the associated entries. For a destructive operation with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence in Japanese that conveys purpose clearly. There is zero waste. However, it is arguably under-specified rather than concise, but for a single-parameter CRUD delete tool, this length is appropriate.
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?
This is a destructive mutation tool with no annotations and no output schema. Given the ambiguity with the sibling 'delete_relationship' and the lack of behavioral disclosure (reversibility, dependencies, what gets deleted), the description is not sufficiently complete for an agent to confidently invoke it, especially to decide between delete_relation and delete_relationship.
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 schema documents the single 'id' parameter with description '関連ID'. The description itself adds no parameter information beyond the schema. With 100% coverage, the baseline is 3, and the description doesn't provide anything extra (e.g., ID format, source of the ID), so 3 is appropriate.
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 'エントリ間の関連を削除' (delete relations between entries) states a clear verb+resource: it deletes a relation. However, it does not distinguish itself from the sibling 'delete_relationship' which appears semantically identical, nor does it clarify the relation to 'create_relation' and 'get_relations' beyond the obvious CRUD pattern.
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. Notably, there is a sibling 'delete_relationship' that seems functionally identical, and no explanation of when to use relation deletion versus tag/entry deletion. No exclusions or alternatives 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies destructive behavior, but the description does not state whether deletion is permanent, whether it cascades to related entities, whether confirmation is involved, or whether there are any side effects. For a destructive tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence in Japanese that conveys the core purpose without waste. However, it is under-specified for a destructive operation - being brief is good, but the brevity sacrifices needed behavioral context.
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, no output schema, and only one parameter, this description should compensate with richer context. A destructive relationship deletion tool needs to clarify whether this affects related entries, tags, or other relationships. The minimal single-sentence description leaves significant gaps for an agent deciding whether and how to invoke this 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% and the single parameter 'id' is documented as 'エントリID (UUID)' in the schema. The description adds no additional meaning about what type of relationship ID this expects or any ID format requirements beyond the schema. Baseline 3 is appropriate since the schema already covers the parameter.
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 '人間関係を削除' (Delete human relationship) clearly states the verb (delete) and resource (relationship), which is adequate. However, it does not distinguish from sibling tools like delete_relation or delete_custom_entry, nor clarify what '人間関係' specifically refers to versus create_relationship/update_relationship 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 alternatives. There are many similar delete tools (delete_relation, delete_persona, delete_custom_entry) and no exclusion or distinction is provided. The description does not state any prerequisites (e.g., relationship must exist) or context for appropriate use.
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. The description only says 'get by ID' — it doesn't disclose whether this is a read-only operation, what happens if the ID doesn't exist (error vs empty), whether it requires authentication, or what the return format looks like. For a retrieval tool with zero annotation coverage, minimal behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It's appropriately brief for a simple single-parameter getter tool. It could arguably be considered under-specified, but for clear get-by-ID semantics, this length is reasonable.
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 simple single-parameter getter with full schema coverage and no output schema, the required context is modest. However, with zero annotations and no mention of return behavior, error handling, or how this differs from the many sibling get_* tools, the description is incomplete for safe agent invocation. The tool is straightforward enough that a 3 might be defensible, but the absence of any behavioral notes tips it to a 2.
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% (the id parameter is documented as 'エントリID (UUID)'). The description adds 'IDで指定' which reinforces that the tool looks up by ID, but adds no additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate given full schema coverage.
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 '趣味を取得 (IDで指定)' translates to 'Get hobby (specified by ID)', which clearly states the action (get) and resource (hobby) with an ID-based lookup. However, it lacks sibling differentiation — there are sibling tools like get_custom_entry, get_skill, get_project, etc., all with similar ID-lookup semantics, and this description doesn't distinguish when to use this particular entry-getter over others.
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 when-to-use guidance is provided. The description merely states the operation without mentioning any context for when to invoke this vs list_hobbies or other get_* siblings. There's no mention of prerequisites, error conditions, or alternative tool selection guidance.
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 'retrieve' which implies a read operation, but doesn't state whether it returns the full project with nested entries, whether deleted projects are excluded, or any pagination/return format behavior. For a simple lookup this is a modest gap.
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?
A single brief sentence with no waste. It's appropriately minimal given the single-parameter simplicity. Could arguably be more informative, but it's well-structured and front-loaded.
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 simple get-by-ID tool with no output schema and no annotations, the description doesn't explain the return structure or any edge cases. With one parameter and a clear read purpose, it's functional but leaves the agent guessing about what a project object contains. Sibling tools like get_custom_entry likely return similar shapes, so the agent must guess.
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% and the only parameter 'id' is already described as 'エントリID (UUID)' in the schema. The description's '(IDで指定)' adds nothing beyond what the schema already states. Per the high-coverage baseline, a 3 is appropriate.
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 'プロジェクトを取得 (IDで指定)' states the action (retrieve a project) and resource (project), and notes it's by ID. However, it doesn't distinguish this from siblings like list_projects (which retrieves all) or get_custom_entry (which is a different resource type). The purpose is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention when to prefer get_project over list_projects, nor any context about what situations warrant fetching a single project. Sibling differentiation is absent.
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 of behavioral disclosure. It's a read operation (safe, non-destructive) but this is not stated. The profile_id description does mention account-scoped vs profile-scoped API key behavior, which is helpful context about auth requirements, but the description itself adds nothing beyond the schema about granular/destroy behavior, rate limits, pagination semantics, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single terse Japanese sentence with zero waste. Front-loaded and efficient. However, at only 10 characters, it might be under-specification rather than conciseness—a slightly more descriptive line about filter/pagination capabilities would improve value without bloating it.
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 6 parameters including nested objects (filter), no output schema, and no annotations, the description should compensate significantly but doesn't. The schema covers the params well, but there's no mention of what the response contains, whether list_custom_entries vs list_health_entries vs list_profiles have different data shapes, or any limits/philosophy of the list. The description is adequate for simple routing but incomplete for a tool with this many options.
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 baseline is 3. The description itself adds no parameter-level info beyond what the schema already states. However, the schema is quite rich (limit range, filter semantics as column:value map, offset, sort column, order direction, and profile_id auth scoping), effectively carrying the semantic burden. The description doesn't add value beyond schema but also doesn't need to compensate for gaps.
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 "健康エントリ一覧を取得" (Get health entry list) clearly states the verb (get/list) and resource (health entries), making the purpose identifiable. However, it doesn't distinguish this from the numerous sibling list tools (list_projects, list_skills, list_career_entries, etc.) beyond name differentiation, nor does it clarify the list's scope or what fields/entities are returned.
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 alternatives like get_health_entry, search, or list_profiles. For a tool with a filter parameter and profile scoping, there's no mention of how it relates to get_health_entry (single-item fetch) or the search tool. No exclusions, context, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention whether this is a read-only operation, any authentication requirements, pagination behavior, or how profile scoping (account vs profile-scoped keys) affects results. The parameter descriptions cover some scoping semantics, but the tool description itself reveals nothing about runtime 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 a single concise sentence with zero filler. However, it's borderline under-specification rather than deliberate conciseness—while nothing is wasted, the brevity leaves key guidance gaps that other dimensions penalize.
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 listing tool with 6 parameters and no annotations, no output schema, and no usage guidance, the description is inadequate. The schema covers parameter mechanics, but the description fails to explain return format, pagination semantics, profile-scoping rules, or distinguish this from list_available_personas. The nested filter object and profile_id scoping complexity warrant more explanation than a single clause.
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 six parameters have descriptions in the schema. The schema covers limit, offset, order_by, order_desc, filter, and profile_id semantics. With full coverage, the baseline of 3 applies; the description adds no additional parameter nuance beyond what the schema already documents.
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 "ペルソナ一覧を取得" (get list of personas) identifies the verb (取得/fetch) and resource (ペルソナ一覧/persona list) clearly. However, it does not differentiate from closely related siblings like list_available_personas or get_persona, providing no scoping or filtering nuance to help distinguish it from those alternatives.
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 list_available_personas, get_persona, or search. The schema hints at account/profile scoping (profile_id required for account-scoped keys), but the description itself provides no when-to-use 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 the full burden of behavioral disclosure. It does clarify that the preview contains no context body and only entity counts, which is useful. However, it doesn't disclose read-only behavior, output format, whether it's a preview of a snapshot, auth requirements, or side effects. For a data-preview 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise — a single line in Japanese with a parenthetical clarifying scope. It's efficient and front-loaded with the purpose. However, it omits behavioral details that could earn their place, so while it's concise, some brevity comes at the cost of 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 no output schema and no annotations, the description should compensate by explaining what the preview returns. It states 'entity count only,' but doesn't clarify which entities, how counts are grouped, whether perspersona is required for preview filtering, or the relationship to generate_nft_snapshot and get_nft_listing. For a tool with one optional parameter and no output schema, this leaves significant ambiguity.
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% for the single 'persona' parameter, which the schema documents as 'ペルソナ名'. The description doesn't clarify how persona relates to the NFT preview (does it filter the preview by persona?). Baseline 3 is appropriate since the schema fully documents the parameter, though the description adds no semantic enrichment beyond that.
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 states the tool displays an overview of Mini data (no context body, entity count only), identifying a distinct purpose: previewing NFT data rather than generating or listing it. However, it doesn't use an explicit verb+resource structure and is somewhat ambiguous about what 'Mint' refers to or what 'data preview' produces. It partially distinguishes from siblings like generate_nft_snapshot and get_nft_listing, but not clearly.
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 when-to-use guidance or alternative tool references. The description doesn't explain when to preview NFT data versus when to use get_nft_listing, generate_nft_snapshot, or get_nft_data. Context is implied by the name (preview) but no exclusions or alternatives 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 carries full responsibility for behavioral disclosure. '更新' implies mutation, but the description doesn't state whether the operation is partial (merging provided fields) or full replacement, whether the id must reference an existing category, how errors are surfaced, or what happens to fields not included in the update. For an update tool with zero annotation coverage, more transparency is warranted.
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 zero waste. However, the brevity borders on under-specification since it adds no behavioral or usage context — it's efficient but not informative enough.
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 2 params (one nested object with 3 subfields), no output schema, and no annotations. The one-sentence description doesn't address update semantics (merge vs replace), the meaning of schema_hint, required validation, or what the return value looks like. Given the nested object complexity and zero annotation coverage, this is insufficiently 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 description coverage is 50%. The description lists no parameter information, but the schema documents id (エントリID) and data fields (name, description, schema_hint). Notably, schema_hint has only a vague schema description ('期待フィールドのヒント') and the description adds no clarification about this nested object's meaning or required structure. The description adds minimal value beyond the schema.
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 custom category) provides a clear verb+resource pairing. It distinguishes the purpose from siblings like create_custom_category and delete_custom_category by the update verb, though it lacks specification of what fields or scope are updated. It's minimally adequate but doesn't add detail beyond the name.
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 vs alternatives. The sibling set includes create_custom_category, get_custom_category, delete_custom_category, update_custom_entry, and list_custom_categories, but the description offers no when-to-use guidance, prerequisites (such as needing an existing category), or distinctions among these related 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a write operation, but the description doesn't state whether the category is globally available or profile-scoped, whether duplicate names are rejected, what happens to existing entries when a category is removed, or what the response contains. The profile_id parameter in the schema hints at scoping behavior, but the description itself discloses no behavioral traits.
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 short sentence with zero waste. It's front-loaded and immediately clear about the action. Nothing extraneous is included.
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 nested objects (data object with its own sub-properties including schema_hint), 2 parameters, no output schema, and no annotations. The description says nothing about what a custom category is used for, how it relates to custom entries, what the schema_hint parameter controls, or what kind of response to expect. For a create operation with nested structures and no output schema, the description is notably thin—it should explain the category's role in the broader data model and clarify the purpose of schema_hint.
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 50% (2 of 4 total properties documented, though 2 are top-level and 2 nested). The description adds nothing about parameters beyond what the schema provides. The name and description fields are documented in the schema with 'カテゴリ名' and '説明' respectively. The profile_id field has a reasonably detailed schema description covering account vs profile-scoped key behavior. The description itself contributes zero parameter guidance, making it at baseline given partial schema coverage.
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 'カスタムカテゴリを新規作成' (Create new custom category) provides a clear verb+resource pairing, and given the sibling tools like update_custom_category and delete_custom_category, it effectively communicates that this is the creation operation. However, it doesn't specify WHAT a custom category is, what fields are involved, or how it differs from create_custom_entry, which is a closely related sibling. It's adequate but lacks contextual differentiation beyond the verb.
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 about when to use this tool versus alternatives. There's no distinction between custom categories and custom entries, no mention of whether categories are required before creating entries, and no conditions or prerequisites described. The schema_parameter for profile_id partially explains account vs profile scoped keys, but this is in the schema, not the description. For a tool among many similar create_* siblings, this is insufficient guidance.
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. The description gives zero information about side effects (e.g., whether creation requires authentication, whether duplicate titles are rejected, whether a profile association is mandatory, or what the created resource's state is). For a write 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste, but it's under-specified rather than genuinely concise. There is no front-loading of key details because there are no details to front-load. The brevity trades away useful behavioral and selection context.
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?
This is a create/mutation tool with no output schema, no annotations, and a complex nested input (11 sub-fields in 'data'). The description does nothing to explain required fields, default values, validation, or what happens on creation. Given the complexity of the data object, the description is inadequate for guiding 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 50% with 2 top-level parameters. The schema itself documents 'data' as a nested object with well-described sub-fields (type, title, status, progress range, etc.), and the profile_id field includes a detailed description about account vs profile-scoped behavior. The description adds no additional parameter semantics, but the schema is already reasonably self-documenting, and the coverage covers the two top-level params despite the 50% figure applying to all nested fields.
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 '目標を新規作成' (Create new goal) clearly states a verb+resource (create a goal), but it's minimal and doesn't add anything beyond the name create_goal itself. It doesn't distinguish from sibling tools beyond the obvious goal vs other resources, though the name already conveys this.
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 essentially no usage guidance. The description doesn't explain when to use create_goal vs create_project or other create_* siblings, nor does it mention prerequisites like whether a profile must exist first, whether profile_id is needed, or when to prefer other tools. The profile_id schema field hints at scoping but the description is silent.
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 doesn't state whether this is a mutating operation, what side effects occur, whether the project is associated with a profile, or any constraints on creating projects. The description merely restates the creation action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient. However, it's underspecified for a tool with 13 nested properties and 2 top-level parameters. The description could earn its length by adding more context about the project creation semantics rather than just restating the action.
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?
This is a complex create operation with a nested data object containing 13 fields, no output schema, and no annotations. The description gives no indication of what a successful creation returns, whether there are required dependencies (e.g., profile_id), or any validation constraints beyond what the schema states. For a CUD operation with this complexity, more contextual explanation is needed.
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 50%, meaning many nested parameters (url, role, tags, type, lessons, metadata, outcomes, confidence, importance, period_end, description, period_start, technologies) have their own descriptions within the schema. However, the profile_id parameter description is notably detailed (explaining account-scoped vs profile-scoped key behavior). The data payload params are well-described in the schema itself, though the top-level description doesn't add semantic depth beyond schema.
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 'プロジェクトを新規作成' (Create a new project) uses a clear verb+resource structure that distinguishes it from siblings like get_project, list_projects, update_project, delete_project. However, it doesn't specify what a 'project' contains or what makes this distinct from other create_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are many sibling create_* tools (create_profile, create_skill, create_goal, etc.), and the description gives no indication of when a 'project' is the appropriate entity versus other types, nor any prerequisites or context for creating a project.
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 behavioral disclosure burden. 'タグを作成' only states the create action without revealing what happens on creation (duplicate handling, required permissions, relationship to tag_entry, or whether categories are validated). For a mutation tool with zero annotations, 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?
A single concise sentence 'タグを作成' with zero waste. Perfectly efficient for stating the core action, though it sacrifices detail for brevity.
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 mutation tool with no annotations, no output schema, and limited sibling differentiation, the description is thin. It doesn't explain return values, error conditions, duplicate tag behavior, or the distinction between create_tag and the many related tag tools (tag_entry, untag_entry, list_tags). Given the tag ecosystem complexity, more context is warranted.
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 both name and category parameters have basic descriptions. The description adds 'タグを作成' which implies name is the tag being created, but doesn't clarify how category relates to the tag structure or whether it's optional in practice. Baseline 3 is appropriate given full schema coverage.
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 'タグを作成' (Create tag) uses a specific verb+resource combination that clearly indicates the tool creates a tag. However, it doesn't add any detail distinguishing it from siblings like tag_entry or untag_entry, which operate on tags differently. The purpose is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description doesn't clarify when to use create_tag versus list_tags, tag_entry, or untag_entry. For a tag management toolset, this lack of guidance leaves the agent guessing about which tag operation to invoke.
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. '削除' (delete) implies destructive behavior, but the description doesn't state whether the deletion is permanent, whether it cascades to related entries (e.g., tags, relations), or what happens after deletion. For a destructive mutation tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that earns its place - it clearly states the verb and resource. It's appropriately minimal for a simple delete-by-id operation, though it could include a brief note about the destructive nature without being verbose.
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 delete tool with one well-documented parameter and no output schema, the description is mostly adequate. However, since it's a destructive mutation with no annotations, it would benefit from a note about irreversibility or cascade effects. The simplicity of the tool (one ID parameter) keeps the completeness score at a reasonable baseline.
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 - the single 'id' parameter is described as 'エントリID (UUID)'. The description itself adds no parameter semantics beyond the schema, but since the schema fully documents the id parameter, the baseline of 3 is appropriate. No additional context is needed given only one UUID parameter exists.
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 '価値観・哲学を削除' (Delete values/philosophy) states a specific verb (delete) and resource (values/philosophy), clearly distinguishing this from sibling tools like create_values_philosophy and update_values_philosophy. However, it lacks detail about the scope or effect, and the name is very similar to siblings so it's not differentiating beyond the verb.
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 deleting other entry types (delete_custom_entry, delete_episode, etc.) or when deletion might be irreversible. The context implies that this tool deletes a specific values/philosophy entry by ID, but no exclusions or alternatives 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 provided, the description carries the full burden of behavioral disclosure. It only states 'get' which implies a read operation, but doesn't reveal whether the entry must belong to the authenticated user, what happens if the ID doesn't exist (error vs empty result), or any permissions needed. For a read tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence in Japanese, with zero wasted words. It front-loads the purpose. While brief, it's appropriately minimal for such a simple single-parameter retrieval tool.
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 single-parameter get-by-ID tool with 100% schema coverage and no output schema, the description is mostly adequate. However, given zero annotations, it doesn't address expected error behavior on missing IDs, authorization scope, or returning null vs error. Sibling tools exist (list_achievements) whose relationship isn't clarified. It's minimally viable but has clear gaps for a tool in a large sibling set.
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 schema already documents the single 'id' parameter as an entry ID (UUID). The description's '(IDで指定)' parenthetical merely restates what the schema says, adding no value beyond it. Baseline 3 is correct since the schema does full documentation work.
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 '実績を取得 (IDで指定)' states 'Get achievement (specified by ID)' in Japanese, which is a specific verb+resource combination. However, it does not distinguish from siblings like get_hobby, get_skill, get_project which all follow the identical get-by-ID pattern. The purpose is clear but there's no differentiation from the many parallel 'get_X' siblings, so it doesn't fully help an agent select among the get_* family.
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. Sibling tools include list_achievements and create_achievement, but the description never explains this is the single-record retrieval counterpart to list_achievements. No context or exclusions are given for when an agent should pick this tool over its siblings.
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. The description only states it retrieves a category by ID but doesn't disclose error behavior (e.g., what happens with nonexistent ID), whether this is a read-only operation, or any side effects. For a simple get tool this is somewhat acceptable, but with zero annotation coverage, more context would help.
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 in Japanese that states the purpose efficiently. No wasted words. It is front-loaded and appropriately short for a simple single-parameter get tool.
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 single-ID read operation with 100% schema coverage, the description is largely adequate. However, given zero annotations and no output schema, it could mention what the response contains (category structure) or note prerequisites. It's functional but at the minimum viable level.
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 the only parameter 'id' described as 'エントリID (UUID)'. The description's 'IDで指定' confirms ID-based lookup, which matches the schema. Baseline 3 is appropriate since the schema already documents the parameter fully and the description adds minimal value.
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?
Description states 'カスタムカテゴリを取得 (IDで指定)' which is 'Get custom category (specified by ID)', a clear verb+resource. However it does not distinguish from siblings like get_custom_entry or similar get_* tools beyond the resource name. The purpose is understandable but minimal and doesn't add scope or differentiation context.
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 alternatives. With many get_* siblings (get_custom_entry, get_persona, list_custom_categories), there's no mention of when to use get vs list, or which scenario fits this tool. The description lacks any 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 the full burden of behavioral disclosure. As a read/get operation, one would expect safety expectations to be clear, but the description provides no behavioral details—no mention of return format, error behavior for invalid IDs, authorization requirements, or relationship to other custom-entry tools. The description adds nothing about behavior beyond what the name implies.
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—extremely concise and to the point. It has no filler or redundant phrasing. However, it is likely under-specified rather than optimally concise; the brevity is partly due to lack of useful content rather than disciplined compression.
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 single-ID get operation with one parameter and full schema coverage, the description is functionally adequate. The pattern of 'get X by ID' is well-understood and matches siblings (get_hobby, get_persona, etc.). However, it doesn't clarify whether the returned entry includes related data like tags or whether pagination or partial responses apply, which could matter given the rich custom-entry ecosystem.
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 the single 'id' parameter documented as 'エントリID (UUID)'. The description's mention of 'IDで指定' aligns with the schema, but the description itself adds minimal meaning beyond the schema—it just restates what the schema property already documents. With baseline 3 for high schema coverage, this is acceptable since the schema handles parameter documentation.
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 states 'カスタムエントリを取得 (IDで指定)' which means 'Get custom entry (specified by ID)'. The verb 'get' combined with the resource 'custom entry' is clear, and specifying 'by ID' adds a scoping detail. However, it doesn't distinguish from siblings like get_custom_category, get_hobby, etc., beyond the resource name—though the resource itself ('カスタムエントリ' vs others) provides some 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?
The description gives no context on when to use this tool versus alternatives. There is no mention that this is for retrieving a single custom entry by ID while list_custom_entries retrieves all, nor any guidance on when custom entries are preferable to other entity types. Usage context is entirely implied by the tool's name and sibling structure.
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 only states it retrieves education data by ID and returns nothing about read-only behavior, error conditions (e.g., not found behavior), required permissions/auth, or what happens on invalid UUIDs. For a read operation without annotation support, it should at least confirm non-mutating behavior and describe response shape.
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 (学歴・教育を取得 (IDで指定)) that efficiently communicates the purpose. It's appropriately short for a simple get-by-ID operation. 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 (1 param, read operation, likely returns a single education record). The description, combined with the schema, is mostly adequate. However, without annotations or an output schema, and with no mention of what fields the returned education entry contains or behavior on missing IDs, it could be slightly more complete. The minimal complexity keeps the gap small.
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% and the single 'id' parameter is already well-documented as 'エントリID (UUID)'. The description adds no additional meaning beyond confirming the ID selects which education entry to fetch. With full schema coverage and a single simple param, baseline 3 is appropriate.
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 '学歴・教育を取得 (IDで指定)' clearly states the action (get education by ID) and the resource (education/history). However, it doesn't explicitly distinguish from siblings like list_education, create_education, or get_skill/get_hobby which follow the same pattern. The verb+resource is clear but sibling differentiation is weak since all get_* tools look identical.
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 vs alternatives. It doesn't mention that list_education would be used to enumerate without an ID, or that create/update/delete handle mutations. The description only says 'get by ID' which implies some usage context but provides no exclusions or alternative selection 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. It only states what the tool does (retrieve by ID) but doesn't disclose what happens if the ID doesn't exist (error behavior), whether related data (tags, relations) is included, or read-only semantics. It adds minimal beyond the name.
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?
Extremely concise single sentence. For a simple single-parameter getter, this is appropriately compact with no wasted words. Could arguably add a bit more context, but for the simplicity level this is well-sized.
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 single-parameter getter with 100% schema coverage and no output schema, the description is largely adequate. The tool retrieves a health entry by ID—the core purpose is clear. However, no annotations and no description of return contents or not-found behavior slightly reduce completeness, but this is acceptable for a simple read 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 coverage is 100% with a single 'id' (UUID) parameter already described in the schema. The description's parenthetical '(IDで指定)' reinforces that the id parameter is the lookup key but adds nothing beyond what the schema already documents. Baseline 3 is appropriate.
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 '健康エントリを取得 (IDで指定)' states a clear verb+resource (retrieve health entry) and specifies it's by ID. It's a simple single-resource getter with an obvious purpose. However, it doesn't explicitly distinguish from siblings like get_hobby or get_skill, though the resource name already differentiates 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 on when to use this vs alternatives. With many sibling get_* tools, there's no mention of when to prefer this for health entries versus other retrieval tools, nor any nuance about health-entry-specific considerations.
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 full burden. The description implies a read operation ('取得' = fetch) which suggests non-destructive behavior, but it doesn't disclose anything beyond that — no mention of whether a missing ID returns an error, whether it's read-only, or what the response looks like. For a fetch tool the functional intent is reasonably inferable.
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 in Japanese that directly states the tool's purpose. No wasted words, though it could arguably be slightly more descriptive. It's appropriately brief for a simple single-parameter fetch tool.
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?
This is a very simple tool (1 param, no output schema, no nested objects), so the completeness bar is lower. The description plus schema adequately convey the operation for a basic single-record fetch. However, given the crowded sibling space with similar persona retrieval tools, slightly more context about what distinguishes this from list_personas would improve completeness.
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 the sole parameter 'id' documented as 'エントリID (UUID)' in the schema itself. The description adds no additional parameter context beyond what the schema already provides. With full coverage at a single parameter, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ペルソナを取得 (IDで指定)' states 'get persona (specified by ID)' which clearly communicates a read operation on a persona resource. However, it doesn't distinguish this from the sibling tools list_personas and list_available_personas, which could easily be confused for retrieval operations. The verb+resource is clear but differentiation from siblings is absent.
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. Given the sibling tools include list_personas and list_available_personas, the description should clarify that this tool fetches a single persona by ID while the list variants return collections. No exclusions or alternative references are given.
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. The description only states it retrieves a list, with no mention of default behaviors, pagination semantics, filtering capabilities beyond the schema, or any side effects/read-only guarantee. For a read operation with zero annotation coverage, this is a significant gap in a system with many mutation tools.
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 wasted words. It's appropriately minimal but doesn't over-exploit brevity at the cost of substantive context.
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 6 parameters including a nested filter object and a profile_id with complex scoping rules. With no annotations and no output schema, the description provides only a minimal one-line purpose. Given the availability of sibling episode tools (create/get/update/delete_episode) and the parameter complexity, a richer description could clarify when filtering is needed, how profile scoping works, and what the response structure looks like.
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 6 parameters have schema-level descriptions. The description adds nothing beyond the schema. The filter parameter's semantics ('カラム名: 値') is defined only in schema. With full coverage, baseline 3 is appropriate - the schema does the heavy lifting.
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 Japanese description 'エピソード一覧を取得' (get episode list) clearly states the verb+resource purpose. However, it doesn't add scope/filtering nuance that distinguishes it from sibling tools like list_custom_entries, list_career_entries, or get_episode, which are all conceptually similar list operations.
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 vs alternatives is provided. The description doesn't mention it's for listing episodes specifically (as opposed to other resource listings) or any use context. The profile_id parameter description hints at scoping but that's parameter-level, not usage guidance.
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. '更新' (update) implies mutation, but the description doesn't state whether the update is partial (merging) or full replacement, whether it requires existence of the record, what happens when data is missing, or who has authorization. The schema shows data is optional fields, but behavior of the update operation itself is undisclosed.
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?
At a single short sentence, it's economical and contains zero waste. However, it's under-specified for the tool's complexity - a multi-field profile update with dozens of nested properties deserves more than three words. This is under-specification rather than genuinely good 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?
This is a high-complexity tool with no output schema and no annotations. The description is a bare minimum that doesn't explain update semantics, success/error behavior, validation rules, or relationship to create_profile and analyze_profile siblings. For a tool with such a large nested data schema, this falls well short of adequate documentation.
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 description adds no parameter information, but the schema itself is extremely detailed with field-level Japanese descriptions for each property (bio, mbti, tone, urls, etc.). However, schema description coverage is only 50%, meaning roughly half the parameters lack descriptions - and the description doesn't compensate for that gap. The top-level id and data parameters are documented in the schema sufficiently, so the baseline is near the higher end.
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 profile) states a clear verb+resource, which distinguishes it from creation/deletion tools like create_profile and delete_profile. However, it doesn't specify what fields or behaviors beyond the generic 'update' concept, and with siblings like update_persona, update_custom_entry, and update_career_entry, the specific profile context is only implied by the name.
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 create_profile or update_persona. The description doesn't state whether this is a partial or full update, how the id relates to existing profiles, or when create_profile should be used instead. The context of a profile update is implied but never articulated.
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 mentions 'scoring identifies compression candidates' but doesn't disclose what side effects exist (if any), whether this is a read-only operation, whether it modifies data, rate limits, auth requirements, or what the returned analysis looks like. For a tool that computes scores and suggests deletions, the absence of explicit 'read-only/no-modification' clarification is a gap.
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 quite short and front-loaded with the core purpose. However, the mention of 'batch_operations' in the same sentence mixes usage guidance into the purpose statement, and referencing a specific sibling tool name is somewhat fragile/implementation-specific rather than describing general intent. Could be cleaner and more 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?
There is no output schema, so the description should explain what the tool returns (e.g., list of entries with scores, count of candidates). The scoring model, how compression candidates are weighted, and how focus/persona/threshold interact is partially implied but never explicitly explained. For a tool with no output schema and 3 meaningful parameters, the description leaves the actual deliverable unspecified.
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% and each parameter (focus, persona, score_threshold) has a clear description including boost behavior for focus and defaults for persona/threshold. The description adds slight context by framing these as 'scoring' inputs that identify compression candidates, but the schema descriptions themselves already explain each parameter's effect well.
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 states the tool analyzes a profile and identifies compression candidates via scoring, mentioning batch_operations for cleanup. However, it doesn't clearly specify what 'profile' refers to (user's full profile? a specific section?) and the verb+resource is somewhat generic ('プロフィール分析' = profile analysis) without distinguishing precisely what analysis or output it produces compared to get_stats or get_context.
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 mentions combining with batch_operations but provides no explicit when-to-use or when-not-to-use guidance vs alternatives. There's no exclusion criteria, no mention of when this is preferred over get_stats, get_context, or search. A user cannot tell if this is meant for routine analysis or only for pre-cleanup surveys.
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. The description is only 18 characters and reveals nothing about potential side effects, output format details, size limitations, or whether this is a read-only operation. The include_private parameter hints at access control implications, but the description doesn't address data sensitivity or authorization requirements.
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 fluff. It's appropriately minimal for the tool's scope, though it might err on the side of being too terse given its importance as a bulk operation.
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 an export tool that could dump all user data, the description is notably thin. It doesn't mention output format specifics beyond 'JSON', doesn't explain what the include_private flag actually protects/privacy implications, and doesn't note that no output schema exists so the return value format is entirely undefined. The tool name alone suggests bulk behavior but nothing about performance, pagination, or result structure.
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 both parameters (tables and include_private) are already documented in the schema. The description adds little beyond '全データまたは指定テーブル' which just restates the tables parameter concept. Baseline 3 applies since schema does the heavy lifting.
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 states '全データまたは指定テーブルのJSON一括エクスポート' (bulk export all data or specified tables as JSON), which is a clear verb+resource purpose. However, it doesn't distinguish itself strongly from sibling bulk_import or batch_operations beyond being the export counterpart.
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 it exports all data or selected tables, giving some usage context. It doesn't explicitly state when to use this vs alternatives, nor does it mention exclusions or prerequisites, though the schema's table parameter provides some guidance on scoping the export.
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 describes an import operation (which implies mutation/destructive potential) but doesn't disclose whether it overwrites existing data, requires authentication, validates data, handles partial failures, or what happens on conflict. For a bulk operation handling multiple tables, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words. Efficient and to the point. However, it's slightly under-specified given 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?
This is a complex bulk operation on multiple tables with nested object data and no output schema. Given the complexity, the description should mention error handling, validation behavior, whether data is merged/appended/replaced, and what response to expect. None of this is provided. The description is incomplete for such a powerful 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 description coverage is 100% for the single 'data' parameter, and the schema describes it as 'テーブル名をキー、エントリ配列を値とするオブジェクト' (object with table names as keys and entry arrays as values). The description adds '複数テーブル' context but doesn't add meaningful info beyond the schema. Baseline 3 is appropriate for full coverage.
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 states 'JSON一括インポート。複数テーブルのデータを一度にインポート' (JSON bulk import. Import data from multiple tables at once). This has a clear verb+resource and scope (bulk import of multiple tables), but it doesn't distinguish from the sibling 'bulk_export' (which is clearly export) or 'batch_operations' (which could overlap). The purpose is reasonably clear but lacks sibling differentiation.
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 it is used for importing data across multiple tables in one operation, which is a clear use case. However, there's no explicit guidance on when to use this vs. individual create tools (create_* for each entity type), no mention of format requirements (JSON structure), no exclusion criteria, and no mention of whether it replaces or complements single-entity create operations. Context is implied but not explicit.
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. The description does not disclose what happens with an invalid ID (does it error or return null?), whether the entry is a single object or wrapper, or any behavioral characteristics. '取得' implies a read operation, but with zero annotations and no behavioral detail, this is a thin disclosure.
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?
A single concise sentence that states the purpose and selection mechanism. Zero waste, front-loaded meaning. It could arguably benefit from slightly more detail, but for such a simple one-parameter tool, this is appropriately minimal without being under-specified to the point of failure.
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 one-parameter read tool with no output schema and no annotations, the description is minimal. There's no statement about what the response contains, no error behavior, and no distinction from list_career_entries. Given the tool's simplicity, completeness is partially adequate, but the lack of any exclusionary guidance about when to use list instead is a 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 coverage is 100% — the single 'id' parameter is described as an entry ID (UUID). The description adds the context that this ID specifies which career entry to retrieve, reinforcing the schema. With 100% schema coverage and one simple parameter, baseline 3 is appropriate; the description doesn't add meaningful semantics beyond the schema but doesn't need to.
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 '経歴を取得 (IDで指定)' clearly states the verb (get/retrieve) and resource (career/経歴), and specifies it's selected by ID. However, it doesn't distinguish from sibling tools like get_career_entry vs list_career_entries — though the 'by ID' qualifier provides implicit differentiation, it could explicitly note that list_career_entries is for listing all.
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 '(IDで指定)' qualifier implies this is for retrieving a single specific entry by ID, which contrasts with list_career_entries for listing. However, there's no explicit when-to-use versus alternatives guidance, no mention of what makes this different from other get_* sibling tools, and no context about when to prefer this over related 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 full burden for behavioral disclosure. It implies this is a read operation but doesn't state whether it's read-only, whether it aggregates across all categories or a subset, whether results are cached, or what performance implications exist. For a stats tool with no annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese. It's appropriately brief for a zero-parameter read tool. It could add slightly more detail about return structure, but there's no waste or padding.
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?
There's no output schema and no annotations, so the description is the only source of information. It explains it returns category stats (counts, last update) but doesn't explain the return format, which categories are included, or whether filtering is possible. For a tool with zero parameters and no output schema, the description must compensate more.
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 there's nothing for the schema to document. Since schema coverage is 100% (vacuously), a baseline of 4 applies per the rubric for zero-parameter tools. The description does briefly mention what the stats cover (entry count, last update), adding some meaning.
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 states it retrieves category-based statistics (entry counts, last update), which is a fairly specific verb+resource. However, it's a generic stats tool among many CRUD tools, and the description doesn't distinguish it from siblings like list_hobbies vs get_stats, or clarify which categories are covered. It's clear enough but somewhat vague about 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?
No guidance on when to use this vs alternatives. With zero parameters, there's no context provided about what kind of statistics, which data subsets, or how it relates to the many list_* and get_* sibling tools. The description doesn't say when to prefer this over querying individual entities.
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 says nothing about the mutating nature of the operation, error behavior when the tag doesn't exist, whether it's reversible, or authentication requirements. For an operation that modifies state, this is a significant gap with zero annotation coverage to compensate.
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 phrase, which is economical, but it borders on under-specification rather than genuine conciseness. It's not front-loaded with wasted content - it's just minimal. There's no elaboration anywhere that would help an agent, so the brevity here is more a function of absence than efficiency.
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?
This is a mutating tool (removes a tag association) with no annotations and no output schema. The description only states the action at a high level without explaining success/error semantics, the effect of untagging (does it delete the tag itself or only the association?), or how the entry_type enum maps to different tag stores. For an operation that modifies persistent state across 15 possible entry types, the description is inadequate.
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% - all three parameters have descriptions in the schema (entry_id=エントリID, tag_name=タグ名, entry_type=エントリのテーブル名). The entry_type enum is well-defined with 15 valid values. However, the description adds no param semantics beyond the schema. Baseline 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 'エントリからタグを解除' (Untag from entry) clearly expresses the verb (untag/remove tag) and resource (entry). It distinguishes itself from sibling tools like tag_entry (which adds tags) and list_tags/get_entry_tags (which read tags), though it doesn't explicitly name these alternatives. The purpose is clear and specific enough given the tool naming convention.
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. It doesn't mention the relationship to tag_entry (its natural counterpart), nor does it clarify prerequisites like whether the tag must already exist on the entry or what happens when the tag isn't present. The sibling set includes tag_entry and get_entry_tags, but the description fails to position itself relative to these.
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 states the action without disclosing any behavioral traits—whether profile-scoped vs account-scoped API keys behave differently, what validations exist on the free-form JSON content, whether edits are reversible, or whether category_id must exist beforehand. With zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese with no waste. However, it's underspecified—it's so brief that it provides minimal value. Conciseness done well would combine brevity with meaningful content, but here brevity sacrifices informational value.
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 nested objects, 2 parameters, and no output schema. The schema covers parameters fairly well despite 50% coverage. The main missing context is how this tool relates to custom_categories, whether there are validation rules on content, and what the return value is. Given moderate complexity (nested objects, free-form content), the description is somewhat thin but the schema partially compensates.
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 50%. The description adds no parameter-level information. However, the schema itself documents parameters fairly well (title, content as free-form JSON, confidence, importance, tags, metadata, category_id, profile_id with binding rules). The profile_id description in the schema provides useful context about scoped API keys. The description itself adds nothing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'カスタムエントリを新規作成' (Create new custom entry) has a specific verb (create) and resource (custom entry). It's clear and distinct from siblings like update_custom_entry, delete_custom_entry, and get_custom_entry. However, it doesn't explain what a 'custom entry' is or how it relates to custom_categories, which could improve 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 on when to use this tool vs alternatives. It doesn't discuss the relationship with custom_categories (the category_id parameter suggests custom entries belong to categories), or when one might prefer create_career_entry/create_skill/create_achievement over this generic tool. No when/when-not guidance given.
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 for this mutation tool. The description states only that it creates a hobby but doesn't disclose write behavior, whether existing hobbies can be duplicated, what happens on conflicts, or whether the operation is reversible. For a write tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It is front-loaded and efficient. However, it may be under-specified rather than optimally concise given the complexity of the tool.
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?
This is a mutation tool with no annotations, no output schema, and a nested data object with 8 fields. The description says nothing about return values, error behavior, the relationship between profile_id and authentication scopes, or required context. The profile_id parameter itself has important scoping semantics documented in the schema but not reinforced in the description.
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 50%, and the description itself adds no parameter information beyond what the schema provides. The schema documents all 8 nested data fields well (name, tags, metadata, confidence, importance, description, passion_level, related_skills) plus profile_id, so the schema largely does the heavy lifting. The description adds nothing, but the schema's coverage supports a baseline 3.
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 '趣味を新規作成' (create a new hobby) clearly states the verb (create) and resource (hobby), matching the tool name. It distinguishes from siblings like list_hobbies, update_hobby, and delete_hobby through the '新規' (new) modifier, though it doesn't explicitly contrast with 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?
There is no guidance on when to use this tool versus alternatives, no mention of required context (e.g., needing an existing profile), and no exclusions. The description implies creation usage through the verb but provides no context on prerequisites 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 of behavioral disclosure. The description only says 'create a new profile' with no mention of mutation behavior, how data is validated, whether partial data is supported (schema shows all fields optional except name), authentication requirements, or side effects. For a creation tool with 50+ optional fields, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise Japanese sentence with no wasted words. It's appropriately minimal, though it could add a sentence about usage/context to be more valuable. Not verbose, but perhaps slightly under-specified.
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?
This is a complex tool with a deeply nested 'data' object containing 50+ fields, no output schema, and no annotations. The description is too thin for this complexity. It doesn't explain what happens on creation, whether the response returns the created profile, how the large data object is used, or clarify the profile_id scoping behavior. Sibling tools include create_persona (similar concept) with no differentiation between them.
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 50%. The description adds no parameter explanation beyond the schema. The 'data' parameter's structure is well-documented in the schema (all field descriptions present in Japanese). The profile_id parameter has a useful description in the schema about account-scoped vs profile-scoped keys. Since each field has its own description in the schema, the description doesn't need to repeat them, but it also doesn't compensate for the 50% coverage gap on the two top-level 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 'プロフィールを新規作成' (Create a new profile) clearly states the verb+resource action. It distinguishes from siblings like update_profile, list_profiles, get_profile, and delete_profile which have different verbs. However, it doesn't elaborate on scope or distinguish from create_persona which is a closely related resource.
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 alternatives. The schema does note that profile_id is required for account-scoped API keys, but the description itself provides no usage context, no prerequisites, and no exclusions (e.g., vs create_persona).
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. '削除' (delete) implies mutation/destruction, but the description does not disclose whether deletions are permanent, whether the category's associated entries are affected, whether any confirmation/cascade behavior exists, or what the response contains. For a destructive operation with no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It's appropriately short for a simple delete operation, but is slightly under-specified, which is why it's not a 5.
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 low complexity (1 param, no nested objects, no output schema), a destructive tool with no annotations and no behavioral disclosure leaves meaningful gaps. The description should at least note irreversibility or effects on related data. It's functional but thin for a delete 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 description coverage is 100% since the single 'id' parameter is documented as 'エントリID (UUID)'. The description adds no additional semantics beyond the schema, but with full coverage the baseline of 3 is appropriate. The tool has only one well-documented parameter, so the description doesn't need to compensate much.
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 'カスタムカテゴリを削除' (Delete custom category) uses a clear verb+resource construction with a specific, distinct resource. Among siblings there are many delete_* tools but they operate on different resources (entry, persona, skill, etc.), so this is clearly differentiated by 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?
No guidance on when to use this vs alternatives. It doesn't mention that deletion is irreversible, whether it could affect entries referencing the category, or when one might prefer list_custom_categories or get_custom_category first. The when-not case (e.g., category still in use) is absent.
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. The description is minimal ('Get profile') and does not describe the return format, whether partial profile data is returned, if related data (tags, relations, entries) is included, or any potential side effects or required permissions. For a retrieval tool, this is a notable gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence in Japanese. It's efficient and direct with no wasted words. However, given its brevity, it doesn't score 5 because it could have added a bit more useful behavioral context while remaining 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?
With a single parameter, no output schema, no annotations, and a minimal description, this is fairly sparse. Given that there is no output schema, the description should explain what is returned. For a profile retrieval tool, the agent lacks information about whether the result includes nested data or related entries, making it incomplete for confident usage.
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 the 'id' parameter described as 'エントリID (UUID)'. The description adds no new meaning beyond 'get by ID'. The schema already documents the id parameter type and semantics, so the description provides baseline value but doesn't add context about what profile information will be returned for the given ID.
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 'プロフィールを取得 (IDで指定)' (Get profile by ID) uses a clear verb+resource combination, and the parenthetical clarifies it retrieves a specific profile by ID. This distinguishes it from siblings like list_profiles (plural, listing) and create_profile/update_profile/delete_profile. However, the purpose is stated clearly without much elaboration on what constitutes a 'profile' in this domain.
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 gives a clear hint that this retrieves a single profile by ID, which implies it should be used when a specific profile ID is known rather than listing. However, there is no explicit guidance on when to prefer this over siblings like get_custom_entry or get_persona, and no mention of when NOT to use it. The context for usage is implied by the 'by ID' phrasing but not explicitly stated.
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. The description is read-only in nature and mentions preset vs custom personas, but gives no context about return format, pagination, ordering, or whether custom personas include user-created ones vs system configurations.
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 in Japanese, zero waste. It efficiently communicates the core purpose with the parenthetical clarifying scope (preset + custom).
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 zero-parameter list tool with no output schema, the description is adequate but minimal. It could benefit from describing what a persona includes or how the preset/custom split is represented, but the core retrieval behavior is clear enough for a simple list operation.
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?
No parameters exist, so the schema needs no documentation. With 0 parameters, the baseline is 4, and the description appropriately requires no additional parameter explanation.
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 states the tool retrieves available personas (preset + custom), which provides a clear verb+resource. It distinguishes from the sibling list_personas to some extent by noting it includes presets, but doesn't explicitly clarify what differentiates these two list functions.
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 gives no guidance on when to use this tool versus the similar sibling list_personas. For an agent choosing between two list-persona tools, no differentiation or context is provided to help select the right one.
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 for behavioral transparency. It discloses nothing beyond the core function - no mention of auth requirements, no pagination behavior, no sort defaults, no mention of what happens with account-scoped vs profile-scoped keys. The profile_id nuance in the schema is a significant behavioral note that the description omits entirely.
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?
Extremely concise single phrase '経歴一覧を取得' with zero wasted words. It's arguably under-specified, but what's there is efficient. For a list tool with rich schema documentation, this brevity is acceptable, though it borders on too terse for non-Japanese readers.
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?
This is a list tool with 6 parameters, including a conditional required param (profile_id for account-scoped keys), pagination options, and sorting. With no output schema and no annotations, the description should provide more context about return format, authentication scoping behavior, or edge cases. The single Japanese phrase is inadequate for the complexity of this tool's behavior.
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% (all 6 parameters have descriptions in the schema). The description adds no parameter meaning beyond what the schema provides. Notably, profile_id's important conditional requirement is documented in the schema but not reinforced in the description. Baseline 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 '経歴一覧を取得' (Get career list) clearly states a specific verb+resource (list/retrieve career entries) and differentiates from siblings like get_career_entry (single entry) and create_career_entry. However, it doesn't mention filtering or pagination capabilities that are evident in the schema, so it's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. The sibling set includes list_custom_entries, list_hobbies, list_skills, etc., and the description offers no differentiation or context about when listing career entries is appropriate. The profile_id constraint (required for account-scoped keys) is only visible in the schema, not reinforced in usage guidance.
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. The description is a single short sentence that merely restates the tool's function. It doesn't disclose pagination defaults, the profile-scoping behavior (account-scoped vs profile-scoped keys), or sorting defaults—though some of this is partially covered by schema parameter descriptions. A list operation with a filter/sort/pagination contract deserves more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise Japanese sentence with no filler. It's front-loaded and wastes zero words. However, it's arguably under-specified—extreme brevity means missing useful behavioral context—but as a standalone sentence it's clean and efficient.
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 6 parameters, no annotations, and no output schema, the description is too minimal. It doesn't explain the profile-scoping requirements (account-scoped keys need profile_id), pagination behavior, or what the response contains. The tool has moderate complexity (nested objects, filter object) and would benefit from describing its list/filter/pagination contract. The description alone is insufficient for an agent to confidently invoke this.
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 input schema already documents all 6 parameters including defaults (limit=50, order_by=created_at, order_desc=true). The description adds nothing about parameter semantics. Baseline 3 applies since schema does the heavy lifting, and the profile_id parameter has a genuinely informative description explaining the account/profile-scoped key distinction.
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 '学歴・教育一覧を取得' (Get education/education list) clearly identifies the verb (取得/retrieve) and resource (education list), which is a standard list operation. It's distinct enough from siblings like get_education (singular fetch) and create_education/update_education/delete_education (mutations), though it doesn't explicitly differentiate itself from sibling list tools like list_career_entries or list_skills.
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. It doesn't mention distinguishing from list_career_entries, list_skills, or other list tools, nor does it note that profile_id is required for account-scoped API keys (that detail only appears in the schema parameter description). No exclusions or alternatives are 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention pagination defaults, ordering behavior, filtering semantics, or the fact that results may be scoped by profile. The schema reveals parameters like order_by defaulting to period_start and order_desc defaulting to true, but the description itself discloses nothing about 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?
A single concise sentence in Japanese. No wasted words, front-loaded with the core purpose. It's minimal but entirely appropriate — the schema handles the parameter details.
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 list tool with no output schema and no annotations, the description is quite sparse. It doesn't mention defaults like the 50-item limit, default ordering, or pagination for large result sets. The schema compensates for parameter details, but the overall behavior of the list operation (pagination, ordering defaults, profile scoping implications) is left implicit. A bit more context would help.
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 description coverage is 100%, so the schema already documents all 6 parameters with descriptions. The description adds nothing extra, but per the rubric, high schema coverage earns a baseline of 3. The profile_id description in the schema is notably detailed about account-scoped vs profile-scoped key behavior, which is genuinely helpful. The nested filter object is documented as 'フィルタ条件 (カラム名: 値)'. This justifies a 4.
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 'プロジェクト一覧を取得' (retrieve project list) clearly states the action and resource. However, it's quite terse and doesn't distinguish from list_personas, list_profiles, list_goals, etc. — though the resource name 'projects' is clear enough given the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. However, the schema's profile_id parameter description does note that profile_id is required for account-scoped API keys and optional for profile-scoped keys, which adds useful context. There's no mention of exclusions or alternatives.
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. The description only states a fetch/list operation with no information on return format, pagination behavior, ordering semantics, or any side effects. With zero annotation coverage and only a one-sentence description, there's substantial unmet behavioral transparency need.
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 that conveys the core purpose without waste. For a simple list operation in Japanese, this brevity is arguably appropriate, though it does err on the side of under-specification rather than genuine 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?
This is a list tool with 6 parameters, no output schema, a nested filter object, and no annotations. The one-sentence description doesn't explain return value structure, pagination behavior, or the interaction between profile_id and API key scoping. Given the complexity of the parameter surface (nested filter, scoping requirements) and lack of output schema, the description should provide significantly more guidance.
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 schema already documents all 6 parameters. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema handles the heavy lifting, though the nested 'filter' object with additionalProperties for column-value pairs could use more explanation in the description.
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 'スキル一覧を取得' (get list of skills) clearly states the verb (取得/get) and resource (スキル一覧/skill list). It distinguishes from sibling list_* tools since each is named for its targeted resource type. However, it doesn't add detail about the scope or context of what a 'skill' is beyond the name.
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 vs alternatives. There are many sibling list_* tools (list_projects, list_goals, etc.) that share the same pattern, and the description offers no differentiation. The schema's profile_id parameter implies context about profile-scoped vs account-scoped API keys, but this is in the schema, not the description, and no usage context is described.
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. For a mutation tool (an 'update'), it doesn't state whether updates are partial (patch-style) or full replacements, whether the existing entry must exist first, what happens to unspecified fields, or whether auth/permissions are needed. The vague '更新' (update) provides minimal behavioral transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise Japanese phrase with no wasted words. It's appropriately short, though it errs on the side of under-specification rather than genuine conciseness. One could argue it's too terse given the complexity of the nested data object, but the single sentence is efficient.
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?
This is a mutation tool with no annotations, no output schema, and a nested data object with 9 documented properties plus id. The description ('Update life event') is severely under-specified for this complexity. It doesn't explain update semantics (partial vs full), field constraints, or behavior on missing fields. For a write operation of this complexity, the description provides far too little 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?
Schema description coverage is 50%, with the two required params (id, data) and nested object params (tags, type, title, impact, etc.) documented in the schema with Japanese descriptions. The description itself adds nothing about the parameters. With a nested object and only 50% coverage, the description could have clarified partial vs full update semantics for the data object, but it's silent, landing at baseline level.
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 life event) has a clear verb+resource, correctly indicating the tool updates a life event. However, it doesn't meaningfully distinguish itself from siblings like update_custom_entry, update_career_entry, or the create/get/list variants of life events beyond the resource name itself. Context signals show sibling tools exist for get_life_event and list_life_events, so the verb (update vs get/list) helps differentiate.
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 alternatives is provided. There's no mention of whether this tool is for partial updates, whether it requires an existing entry, or when one might choose update_life_event over other update_* tools. The description gives no context about prerequisites (e.g., the entry must already exist) 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 behavioral disclosure burden. The description indicates a write/mutation operation ('作成') but doesn't disclose whether source and target entries must already exist, whether relationships can be duplicated, whether both IDs must reference different entries, or what happens on failure. With no annotations, this is under-specified 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, compact sentence in Japanese, which is efficient. However, given the semantic complexity of the relation_type enum (8 distinct relationship types) and the directionality semantics of source vs target, the description under-uses its space. It's appropriately short but could front-load more value about the relation_type semantics.
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?
This is a semantically rich tool with 3 enums and directionality concepts, yet no annotations and no output schema exist. The description provides only two examples and doesn't explain directionality conventions, whether relations are bidirectional, or the meaning/semantics of each of the 8 relation_type values. For a tool with this complexity, the description is incomplete and relies too heavily on parameter labels.
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 descriptive parameter labels (source_type, target_type, relation_type, source_id, target_id, description), and enums for the three type parameters give clear allowed values. The description adds the semantic meaning that relation_type expresses causality/demonstration relationships through the examples. However, the description doesn't clarify the exact meaning of each relation_type enum value or how source/target directionality is interpreted, leaving this to the enum labels.
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 creates relationships between entries, with concrete examples like 'エピソードがスキルを実証' (episode demonstrates skill) and '経歴がプロジェクトに繋がった' (career led to project). This distinguishes it from the sibling tools create_*/delete_relation/get_relations. However, it doesn't explicitly name the key verbs beyond '作成' (create), making it slightly 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to create inter-entry relationships, an action distinct from the many create_* CRUD tools. However, it gives no explicit guidance on when to use this vs alternatives, no prerequisites (e.g., that referenced entries must exist), and no instructions on which relation_type enum values are appropriate in which contexts. The usage context is inferred rather than stated.
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. The description mentions 'privacy-filtered' (プライバシーフィルタ済み) which suggests data is sanitized, but it doesn't explain what exactly is filtered, whether any data is mutated or destroyed by this operation, what the output format looks like, or any side effects. For a snapshot-generation tool, it's unclear if this creates a persistent artifact or just returns data.
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 that front-loads the core purpose. It's efficiently written with the key qualifiers (privacy-filtered, pre-mint verification). It doesn't waste words, though it could be slightly more structured for clarity.
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, no output schema, and a tool that has a non-obvious purpose related to NFT minting, the description should explain more. It doesn't clarify the output (is it JSON? a file? a report?), what 'privacy-filtered' encompasses, or how this differs from the closely related sibling tools like preview_nft_data. The current description leaves the agent with significant ambiguity.
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 schema documents both parameters ('persona' and 'max_tokens_hint') with their descriptions. The description adds the notion that this is a privacy-filtered snapshot but doesn't elaborate on how the persona parameter affects the result beyond what the schema says. Baseline 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 states a specific purpose: generating a privacy-filtered profile data snapshot for pre-NFT-mint verification. The verb (生成/generate) and resource (スナップショット/snapshot) are clear. It distinguishes from siblings like preview_nft_data and get_nft_listing by specifying the privacy-filtered and pre-mint verification angle, though it doesn't 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: pre-NFT-mint data verification. However, it doesn't explicitly state when NOT to use this tool versus alternatives like preview_nft_data or get_nft_listing, nor mention any prerequisites (e.g., needing a persona to exist first). The 'before NFT mint' context gives some guidance but no explicit 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?
没有提供annotations,因此描述承担了全部行为披露责任。描述只说明'获取标签',但未提及返回格式、标签是否按特定顺序、空标签时的行为、是否需要认证,或对条目不存在的处理。对于读取操作,信息量不足。
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?
描述是一句简洁日语句子,零冗余。虽然简短,但它是高效的——没有多余的词。对于这样一个简单的双参数工具,简短的单句是适当的。
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?
工具本身很简单(2个参数,无输出schema,无嵌套对象),schema参数覆盖率为100%且有一个枚举。描述足以让人理解基本用途,但对于标签检索工具,缺少关于返回值是什么形式(标签名称?标签ID?)的说明。在简单结构下可评为可接受的但并非出色。
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描述覆盖率为100%,两个参数(entry_type和entry_id)在schema中都有描述。entry_type有一个包含15个值的枚举,已明确列出。描述没有在schema之外增加参数含义,但entry_id与entry_type的语义在schema中已充分说明。基准3在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?
描述明确说明该工具获取条目上附加的标签('エントリに付与されたタグを取得')。动词明确(get)+资源明确(tags on an entry)。与sibling工具如list_tags和tag_entry/untag_entry有区分,但未提及与get_entry相比的特定范围。总体上清晰但不详尽。
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?
没有提供何时使用此工具与替代工具的指导。sibling工具中存在list_tags和tag_entry/untag_entry,但描述未提及何时使用此工具检索特定条目的标签与list_tags列出所有标签的区别。也没有说明前提条件或场景上下文。
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. The one-sentence description reveals nothing about pagination behavior, what fields are returned, ordering defaults (beyond schema hints), or whether listing is scoped to a single profile or global. With zero annotations and a minimal description, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one Japanese sentence), which is appropriately minimal for a straightforward list tool. However, given the richer behavioral context that could be added (pagination patterns, default ordering behavior, profile scoping), it borders on under-specification rather than true 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?
This is a 6-parameter list tool with no annotations and no output schema. While the schema documents parameters well, the description provides minimal context. For a list operation, it would benefit from noting what happens when filter is applied, how pagination interacts with offset/limit, and what the default query scope is (all profiles vs current profile). The profile_id scoping is documented but only in the schema, not reinforced in the description.
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 schema documents all parameters with meaningful defaults (limit default 50, order_by default created_at, order_desc default true). The description itself adds no parameter information beyond what the schema provides. The profile_id parameter's scoping semantics are well-documented in the schema. Per the rubric, baseline 3 applies when 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 '趣味一覧を取得' (retrieve hobby list) clearly states it lists hobbies with a specific verb (取得/retrieve) and resource (趣味/hobbies). It's distinct from get_hobby (singular fetch) and list operations for other resources, though it doesn't explicitly differentiate from sibling list_* tools.
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 doesn't explicitly state when to use this vs alternatives. However, the parameter schema for profile_id provides valuable guidance about account-scoped vs profile-scoped API keys and default behavior with profile-scoped keys. This usage context is embedded in the schema rather than the description, and there's no explicit when-not-to-use guidance.
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 behavioral disclosure burden. The description only states it lists listings but doesn't mention pagination behavior, default ordering, whether it returns all marketplace listings or only the user's, or performance characteristics. For a read/list operation, this is minimal disclosure with no annotations to compensate.
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 compact sentence in Japanese that states purpose efficiently. It's appropriately sized for a simple list operation. While minimal, it has zero waste and is immediate about the core 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?
For a list tool with 3 params and no output schema, the description is adequate but thin. It doesn't mention pagination, sorting default, or what fields each listing contains. Given no annotations and no output schema, the description does the minimum. The sibling set includes get_nft_listing which suggests list/detail pairing, but the description doesn't clarify the relationship.
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% with all three parameters documented (limit, status, my_only). The schema already provides meaningful descriptions including the default for limit (20) and valid status values. The description adds minimal param context but the schema handles parameter documentation well, so baseline 3-4 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 states 'NFT出品一覧' (NFT listing list) and 'マーケットプレイスの出品を一覧表示' (display marketplace listings in a list), which clearly uses a specific verb+resource (display listings). It distinguishes from get_nft_listing (singular retrieval) and related NFT tools like generate_nft_snapshot. However, it's brief and doesn't fully differentiate from potentially overlapping marketplace-related 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 get_nft_listing or when to prefer filtering parameters. There's no mention of alternatives, no when-not-to-use guidance, and no context about typical invocation scenarios. The purpose is implied from the name but no explicit usage direction is 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 carries the full burden. The one-sentence description says only that it retrieves a list, but doesn't disclose pagination defaults, filtering behavior, ordering defaults, or that this is a read-only operation. It's a list operation so low destructiveness is implied, but nothing about the return structure, count limits, or authentication scoping (though profile_id parameter hints at scoping).
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 in Japanese. It's efficient and to the point with no waste. However, it's perhaps too terse—a bit more behavioral context would make it more useful without bloating it.
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 list/filter/paginate tool with 6 parameters and no output schema, the description is quite thin. It doesn't clarify pagination behavior, how filter maps to columns, what the default sort is beyond the schema default, or what the response shape is. Sibling tools like list_personas and list_profiles with the same structure suggest this is a CRUD list endpoint, but the description alone doesn't help an agent understand the nuances of filtering (e.g., whether filter values are exact matches, LIKE queries, etc.).
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 schema documents all 6 parameters. The description adds zero parameter context beyond the schema. Baseline 3 is appropriate given full schema coverage. The schema itself is decent (defaults stated for limit, order_by, order_desc, and profile_id has a clear description about scoping behavior).
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 '価値観・哲学一覧を取得' (Get values/philosophy list) clearly states the action (list retrieval) and the resource (values/philosophy). It's brief but distinguishes from sibling tools like get_values_philosophy (single item) and create/update/delete operations. The verb '取得' (retrieve/get) clearly signals a read operation.
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 doesn't state when to use this tool vs alternatives. While the name implies listing and siblings get_values_philosophy suggests single-fetch, there's no explicit guidance about when to use filtering vs pagination, or how it differs from list_custom_entries or other list tools. Some context is implied by the tool name and sibling structure, but no explicit exclusions or alternatives are given.
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 burden. It's a read/search operation and implies no mutation, which is conveyed by '検索' (search). However, it doesn't disclose behavior such as pagination behavior beyond the 'limit' param, result ranking, or how matches are scored/deduped. For a search tool, aspects like relevance ordering would be useful but not strictly required.
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 that conveys the core purpose effectively. No wasted words, front-loaded with the verb '検索' (search). Appropriate brevity for a straightforward search tool. Could arguably be more informative, but this is genuine conciseness, not under-specification.
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?
This is a moderate-complexity tool (3 params, 100% schema coverage, no output schema). The description is adequate for a search tool but omits any mention of the return format, since there's no output schema. The search semantics provided are enough to invoke the tool correctly with the help of schema docs, though return value expectations must be inferred from the broad list of 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?
Schema description coverage is 100%, so the schema fully documents all three parameters (query, limit, tables). The description adds minimal param context beyond the schema. Per the rubric, baseline 3 applies when schema does the heavy lifting, and the description doesn't add syntax or format details beyond what's documented.
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 '全テーブル横断のフルテキスト検索' (Full-text search across all tables) states a specific verb+resource+scope—searching full-text across tables. It's clear about what it does but doesn't differentiate from siblings that do targeted lookups (e.g., list_profiles, list_skills). Given the generic name 'search' and many list_* siblings, it could better clarify how it differs from per-resource listing tools.
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 global search across all tables, which implicitly distinguishes it from per-resource list/get tools. However, there's no explicit guidance on when to choose this over the individual list_* or get_* siblings, and no mention of any constraints or exclusions. The 'all tables' scope is the primary usage signal but exclusions/alternatives are not named.
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 burden of behavioral disclosure. It's a list/read operation which is implied safe, but the description adds no context about pagination response shape, rate limits, or auth requirements beyond the profile_id schema note. The schema's profile_id note does partially compensate for auth-related disclosure.
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 (5 words in Japanese), which is efficient. However, it's under-specified for a tool with 6 parameters, no output schema, and no annotations. The conciseness is appropriate but the substance is thin.
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 list tool with good schema coverage and no annotations, the description is barely adequate. It confirms the resource and action but doesn't describe return format (no output schema exists), pagination behavior beyond offset/limit params, or how filtering interacts with ordering. The 6-parameter complexity plus absent output schema suggests more context would help.
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 all 6 parameters are documented in the schema with descriptions. The profile_id parameter description adds particularly valuable semantics about API-key scoping and required conditions that go beyond basic field names. The description itself adds nothing, but the schema carries the weight well, so the baseline of 3 rises slightly due to the rich profile_id note.
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 "プロフィール一覧を取得" (Retrieve profile list) clearly states the verb and resource. However, it doesn't distinguish itself from sibling tools like list_personas or list_custom_entries, though the name itself is fairly self-explanatory. It's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance. The profile_id parameter description adds meaningful context about account-scoped vs profile-scoped API keys and required scenarios, which is valuable usage direction. But there are no exclusions or alternatives mentioned relative to sibling 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 transparency burden. The description mentions mutating operations (create/update/delete) but doesn't disclose transactional behavior—whether operations are atomic (all-or-nothing) or partially applied, whether there are auth requirements, or what happens on partial failure. For a batch mutation tool this is a significant gap since rollback/atomicity semantics are critical.
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 that packs purpose, scope, and use case. It's front-loaded with the core 'multi-table batch operations' concept. Very little waste, though it could arguably be slightly more detailed given the criticality of the tool.
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?
This is a powerful mutation tool (up to 50 operations across multiple tables) with no annotations and no output schema. The description should disclose atomicity/transaction guarantees, error handling for partial failures, and effects on dependent data. None of these are addressed, making the description under-specified for a tool of this complexity and risk profile.
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 structured schema fully documents the 'operations' array and each sub-field (action, table, id, data). Description adds minimal parameter info beyond that. Baseline 3 is appropriate since the schema does the heavy lifting for parameter documentation.
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 a specific verb+resource combination: executes create/update/delete operations across multiple tables in a single call. It explicitly names the batch nature ('複数テーブルへの...1回で実行') which distinguishes it from the numerous single-entity sibling tools. The purpose is unmistakable and well-differentiated.
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 gives a concrete use case ('近況報告などをまとめてDBに反映する際に使う' - when reflecting multiple updates like status reports to the DB at once), which implies 'use this when you have multiple related DB changes'. However, it doesn't explicitly state when NOT to use it or name specific alternatives (like the individual create/update/delete tools), so guidance is 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.
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 of behavioral disclosure. The description only states that it fetches an episode by ID but doesn't disclose behavior beyond that—no mention of what happens with invalid IDs, whether it returns the full episode or partial data, or related entries. The nested relationship to tags (get_entry_tags exists) is unexplored.
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, front-loaded with the core action. No waste. It could slightly benefit from mentioning it's for a single episode vs list_episodes, but for a simple getter the brevity is reasonable.
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?
This is a simple 1-param read tool with no output schema and no annotations. The description is bare-minimum: it states what it does but provides no context about the episode entity structure, what fields to expect in the response, or how it relates to list_episodes/create_episode/update_episode siblings. Adequate but could add modest context.
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 description coverage is 100% with the id parameter documented as 'エントリID (UUID)' in the schema itself. The single parameter is fully described by the schema, and the description confirms it's used by ID. Little ambiguity remains, so baseline 3-4 is appropriate given full schema coverage.
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 'エピソードを取得 (IDで指定)' clearly states the verb (取得/get) and resource (エピソード/episode) with parameter scope (by ID). It distinguishes from list_episodes which would be the plural variant, though it doesn't explicitly name the sibling alternative.
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?
Usage is implied by the name pattern: get_X retrieves a single entry by ID, contrasting with list_X which presumably lists all. However, there's no explicit mention of when to use this vs list_episodes, no context about when listing vs fetching single makes sense, and no error scenarios or prerequisites stated.
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. The description is purely functional and gives no behavioral context—no mention of what's returned if not found, error behavior, whether the skill is required to exist, or return format. This 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?
A single short sentence that fully states the purpose. No wasted words, efficiently front-loaded. Appropriate minimal length for a single-parameter getter tool.
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 single-ID retrieval tool with one fully-documented parameter and no output schema, the description is arguably adequate—there's little complexity to explain. However, given no annotations and no mention of error/not-found behavior or return content, a slightly fuller description could help.
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%, and the single parameter 'id' is documented in the schema as 'エントリID (UUID)'. The description adds nothing beyond the schema since it just references the ID without additional format or semantics context. Baseline 3 applies given full schema coverage.
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 states the tool fetches a skill by ID, with a clear verb (取得/get) and resource (スキル/skill). It distinguishes from siblings like list_skills (retrieval of a single resource vs listing) and create_skill/update_skill/delete_skill (mutations). However, the differentiation is mild since it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a single-record retrieval tool (by ID), distinguishing it from list_skills. But it doesn't explicitly state when to use this vs alternatives, or note any prerequisites (e.g., the ID must reference an existing skill). No when-to-use or when-not-to-use guidance beyond the purpose.
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. The description only states that it retrieves a values/philosophy entry by ID. It doesn't disclose what happens when the ID doesn't exist (error behavior), whether this is a read-only operation, or what return format to expect. For a retrieval tool with no annotations, this is a notable gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that precisely conveys the tool's purpose with no waste. It front-loads the verb (get) and resource (values/philosophy) and adds the ID scoping qualifier. Every word earns its place.
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?
This is a simple single-parameter retrieval tool with no output schema and no annotations. For a get-by-ID operation, the description is mostly adequate. However, given the absence of annotations and output schema, slightly more context about error handling or return value could improve completeness. The operation is simple enough that the current description is minimally viable but lacks some protective context 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?
The schema has 100% coverage with the single 'id' parameter described as 'エントリID (UUID)' meaning 'entry ID (UUID)'. Since the schema documents the parameter fully, the description doesn't need to add parameter detail. The baseline of 3 is appropriate as the schema does the necessary work and the description's ID reference aligns with the parameter.
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 '価値観・哲学を取得 (IDで指定)' means 'get values/philosophy (specified by ID)' which clearly states it retrieves values/philosophy by ID. It uses a specific verb (get) and resource (values/philosophy), and it distinguishes from siblings like list_values_philosophy (which lists all). However, it's only provided in Japanese without English clarity, which slightly limits universal comprehension.
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 'use this when you need a values/philosophy entry by its ID', distinguishing it from the list variant through the '(IDで指定)' qualifier. However, there's no explicit 'when-not' guidance or mention of alternatives like the list operation for fetching all entries. The usage context is clear from the get-by-ID pattern but no sibling differentiation is explicitly stated beyond the ID scoping.
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 discloses that it returns Markdown and that it's persona-based with weighted boosting (1.5x per schema). However, it doesn't disclose behavior like whether this is read-only, whether it triggers side effects, rate limits, or what 'optimized' means operationally. Moderate transparency with room to add more behavioral detail.
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 that conveys purpose and output in concise Japanese. It's front-loaded with the core function. Could be slightly more structured but achieves its goal without waste.
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 tool with no output schema, the description should explain what return values look like. It does state 'Markdown' as the output format, which helps, but doesn't describe the structure of that Markdown, how max_tokens_hint affects it, or what happens when no persona matches. Given 0 required params and 100% param coverage, it's adequate but could be more complete about the return content.
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 description coverage is 100%, so the baseline is 3. The description adds meaningful context by framing the tool as 'persona-based weighted context' which ties to the persona parameter, and 'optimized Markdown' connects to max_tokens_hint. The focus keyword boosting (1.5x) is described in schema, but the description's 'weighted' concept reinforces the semantic purpose of these parameters. Slight value added over 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 states it generates persona-based weighted context and returns optimized Markdown for AI to understand the person. This is a clear verb+resource+output. It distinguishes itself from sibling tools like get_profile or get_persona by emphasizing 'weighted context' and 'optimized Markdown' generation, though it doesn't explicitly name alternatives.
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 it (when AI needs to understand a person via persona-based weighted context) but doesn't explicitly state when NOT to use it or which sibling tools are alternatives. The focus and persona parameters hint at customization use cases, but there's no explicit guidance versus tools like get_profile or list_available_personas.
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. As a retrieval tool, the read behavior is reasonably implied by '取得' (retrieve), but it does not disclose whether the tool returns the full record, whether it throws or returns null for missing IDs, or whether any related data (tags, relations) is included. For a read-only tool this is a modest gap, not a critical one.
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, compact sentence that conveys purpose and scoping with zero filler. For a simple single-parameter retrieval tool, this is appropriately concise.
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?
This is a simple single-ID retrieval tool with 100% schema coverage of its one parameter and no output schema. The description adequately covers the tool's purpose. It would benefit from clarifying the return format or behavior for missing entries, but for tool of this simplicity the description is largely sufficient.
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% — the single 'id' parameter is documented as 'エントリID (UUID)'. The description restates the ID-based scoping ('IDで指定'), which aligns with but doesn't add much beyond the schema. With full schema coverage and a single well-documented parameter, the baseline 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 'ライフイベントを取得 (IDで指定)' (Retrieve life event, specified by ID) uses a clear verb+resource and specifies the ID-based scoping. It clearly distinguishes from sibling list_life_events (which would be a collection operation) and aligns with the get_* retrieval pattern of siblings. However, it doesn't elaborate on what distinguishes it from related get_* tools beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving a single life_event by ID, which is contextually clear. But there's no explicit when-to-use guidance, no statement of when NOT to use it (e.g., when you need all events use list_life_events), and no alternative tools named. The context is inferred from the retrieval pattern rather than stated.
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:

[![personal-db-mcp MCP server](https://glama.ai/mcp/servers/itoufo/personal-db-mcp/badges/card.svg)](https://glama.ai/mcp/servers/itoufo/personal-db-mcp)

Score Badge

Copy to your README.md:

[![personal-db-mcp MCP server](https://glama.ai/mcp/servers/itoufo/personal-db-mcp/badges/score.svg)](https://glama.ai/mcp/servers/itoufo/personal-db-mcp)

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/itoufo/personal-db-mcp'

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