storyai

by jedikim

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Each tool targets a clearly distinct operation: search (find), read (get, outline), graph navigation (refs, trace, neighborhood), diagnostics (check, impact), and staged writes (ingest, propose, commit). Minor overlap exists between ingest/propose (both create proposals) and check/impact (both diagnostic), but the descriptions draw clear boundaries.
Naming Consistency3/5
Naming is mixed: most tools use imperative verbs (get, find, check, commit, propose, ingest, trace, query), but several are nouns or abbreviations (outline, promises, refs, neighborhood, graph_schema). The pattern is readable but inconsistent across verb and noun conventions.
Tool Count4/5
14 tools is on the higher end but reasonable given the rich domain of narrative graph management, continuity diagnostics, foreshadowing, and staged write workflows. Each tool appears to earn its place, though the count leans toward the heavy side of the ideal range.
Completeness4/5
The surface covers the full lifecycle well: reading (get, outline), search (find, query), graph navigation (refs, trace, neighborhood), schema introspection (graph_schema), diagnostics (check, impact), and staged writes (ingest, propose, commit). Minor gaps exist (no explicit delete/rollback tool, no direct promise mutation), but the workflow demonstrates no dead ends.
Average 3.5/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior, so the description adds the detail about soft edges being included only when requested. This is useful, but does not disclose other behaviors like result ordering, pagination, or the structure of the returned relations. Given the annotation coverage, the omission is mitigated, but not fully addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly stating the core function and the soft-edge condition. It is front-loaded with the primary purpose, which is good, though it sacrifices depth 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?
Given the complexity of 7 parameters, no output schema, and zero schema descriptions, the one-sentence description is far from complete. It fails to explain the return format, the meaning of most parameters, or any edge cases, making it insufficient for an agent to reliably invoke the tool correctly.
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?
With 0% schema description coverage, the description must compensate, but it only hints at the 'dir' parameter (direction of relations) and the 'include_soft' parameter via the soft edges comment. Parameters like rel, as_of, max_chars, and response_format are left unexplained, leaving agents to guess their meaning and usage.
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 that the tool returns relations pointing to or from a given node, using specific verbs and resource. However, it does not explicitly distinguish itself from sibling tools like 'neighborhood' or 'trace', which might overlap in function.
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 its siblings (e.g., 'neighborhood' or 'trace'). The only usage hint is about soft edges being included on request, but no contextual conditions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavior of each include mode (what each returns), which is useful beyond annotations, though it omits details like pagination or error behavior. No contradiction with annotations; annotation_contradiction=false.
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 front-loaded sentence that states the core purpose first, then packs the three include-mode behaviors with zero wasted words. Highly efficient for the information it conveys.
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 5 parameters, no property descriptions, and no output schema, the description only covers the include parameter. ref, as_of, max_chars, and response_format are unexplained, leaving an agent to guess at required input semantics and return expectations for a tool with zero schema-level documentation.
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 0%, so the description must compensate, but it only explains the include parameter. The other four parameters (ref, as_of, max_chars, response_format) receive no description coverage in either the schema or the description, despite ref being required and response_format/as_of having non-obvious semantics.
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 gives a specific verb and resource ('읽습니다' / reads nodes by address), and elaborates the three include modes. It is clear about what the tool does, though the generic name 'get' combined with read-oriented siblings (find, query, neighborhood, trace) means it does not explicitly differentiate itself from 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?
The description explains what the include values (brief/full/body) return, which is useful parameter-level guidance. However, it offers no guidance on when to choose 'get' over read-style siblings like find, query, neighborhood, or trace, and 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable context beyond annotations: it explicitly states that no LLM call is made (important for cost/time) and that nodes and reasoning are returned together. This enriches the behavioral picture without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the core action and rule source, then a second clause highlighting key behaviors (no LLM call, output contents). No redundant words; efficient and clear.
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 5 parameters with zero schema coverage, the description is severely incomplete. It explains the high-level purpose but omits any parameter semantics, expected input formats, or how output is structured beyond 'nodes and reasoning'. While an output schema exists, the description still leaves too much unstated for an agent to invoke it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — none of the five parameters (rules, scope, severity, max_chars, response_format) are described in the schema. The description does not compensate at all; it fails to explain the meaning, defaults, or interplay of any parameter. This is a critical gap for a tool with no other documentation.
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 action (diagnoses continuity) with a clear resource (book or node scope) and mentions the rule source (P2 SQL rules from spec/rules.json). It differentiates itself from siblings by detailing its non-LLM nature and output format, though it doesn't 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other sibling tools. It implies a purpose (continuity diagnosis) but provides no conditions, exclusions, or comparisons. An agent would have to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already identify the tool as idempotent, non-read-only, and non-destructive. The description adds valuable context beyond this: it states that only incremental change proposals are created and that the live graph remains unchanged until commit. This explains the operational behavior and the staging aspect, which is not covered by annotations. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence delivers the core purpose and scope, and the second sentence clarifies the critical behavioral constraint about the live graph. Every word earns its place, and the structure is efficient for an agent to parse quickly.
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 the tool has a parameter count of 2 with one required, and neither parameter is documented in the description, the agent cannot determine what to pass for 'chapter' or how 'mode' alters behavior. Even though an output schema exists, the lack of parameter explanation leaves the tool incomplete for practical invocation. The behavioral note helps, but the missing parameter semantics and lack of sibling differentiation make the overall context insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description makes no mention of the 'mode' (extract/reindex) or 'chapter' parameters. It does not explain what these parameters mean, what values are valid, or how they affect the operation. Since the schema itself provides only names and enums without descriptions, the tool description fails to compensate for this gap, leaving the agent with insufficient guidance for filling 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 states a specific action: validating the hash, UTF-8 byte span, and Scene division of the manuscript and manifest, then creating incremental change proposals. It clearly distinguishes the tool from pure read operations by noting it creates proposals, but it does not explicitly differentiate from the sibling 'propose' tool, which may also generate proposals. The purpose is clear and specific, but sibling differentiation is missing.
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 note 'live 그래프는 commit 전까지 바뀌지 않습니다' (live graph does not change until commit) implies this is a pre-commit validation and proposal step, providing context on when to use it. However, it does not explicitly mention when NOT to use it or name any alternative tools, such as 'check' or 'commit'. The guidance is clear but lacks exclusions or explicit routing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, idempotent=true, readOnly=false. The description adds valuable context about atomicity and conflict handling ('if conflict, no changes applied'), which goes beyond the annotations and clarifies the transactional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action and atomicity guarantee. Every word contributes meaning; there is no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, an output schema exists, and the description covers the core behavior. It could mention the safety of dry_run versus apply, but given the annotations and default mode, the essentials are present. No critical information is missing for correct invocation.
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 0%, and the description does not explain the parameters 'proposal_id' or 'mode'. While 'mode' with enum apply/dry_run is self-explanatory from the description, 'proposal_id' is left undocumented. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply' and the resource 'stored proposal', and specifies atomic execution with a dry_run option. It differentiates from siblings by focusing on committing a previously saved proposal, 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 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 siblings like 'propose' or 'impact'. There is no mention of prerequisites, ordering, or when to choose dry_run over apply. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it specifies traversal along 'reverse hard edges' and that it computes 'related diagnostic rules'. This clarifies what the tool actually does internally. It aligns with the readOnlyHint (read-only) and idempotentHint, with no contradictions, and deepens the agent's understanding of its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and key behavioral aspects. It contains no filler or redundancy, efficiently conveying the tool's function in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description does not explain the input parameters or how to invoke the tool correctly. The agent is left without clarity on what 'ref', 'change', and 'max_depth' should contain or how they affect the computation. Given the zero schema coverage and missing parameter explanations, the description is insufficient for confident correct invocation.
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 coverage is 0%—none of the three parameters (ref, change, max_depth) are described in the schema, and the description does not explain their semantics either. The description only hints that 'change' is a field change, but it does not specify what 'ref' refers to, the structure of 'change', or how 'max_depth' is used. Since the description fails to compensate for the absent parameter documentation, the agent receives minimal guidance.
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's function: read-only precomputation of nodes and diagnostic rules affected by a hypothetical field change along reverse hard edges. It uses a specific verb ('precompute') and resource ('nodes and diagnostic rules'), making the purpose understandable. However, it does not explicitly distinguish itself from sibling tools like 'check' or 'trace', relying on the unique 'impact' focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing the impact of hypothetical changes (before committing), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of when not to use it or what other tools might be better for different scenarios, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to repeat those. It adds algorithmic context (1-hop expansion, token budget) and clarifies the input mechanism (seed and anchors), which is useful. However, it does not disclose limitations, edge cases, or what happens when the budget is exceeded, so it adds only moderate value beyond the 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?
The description is a single, focused sentence with no fluff. It front-loads the core action and constrains the scope. Every word carries meaning, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (graph traversal with a budget) and the presence of an output schema, the description does not need to detail return values. However, it is missing key contextual details: what qualifies as a 'hard edge', how the token budget is allocated, and how 'as_of' fits into the operation. These gaps could lead to incorrect invocation, making the definition only minimally adequate.
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 0% schema description coverage, the description must explain parameters. It does clarify that 'intent' is the seed, 'anchors' are explicit anchors, and 'budget_tokens' is the token budget. However, it neglects 'as_of' entirely and uses jargon ('hard edges') that isn't defined. Thus it covers most but not all parameters, and only partially compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: expanding hard edges one hop from an intent search seed and explicit anchors to produce writing context packets within a token budget. It clearly identifies the verb ('expand'), the resource ('hard edges'), and the output ('context packets'), distinguishing it from siblings like trace or graph_schema.
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 explains what the tool does but provides no guidance on when to use it instead of alternatives such as trace, query, or graph_schema. It does not mention conditions, exclusions, or scenarios where another sibling would be preferred. The implied use case (gathering neighboring context) is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds behavioral context by specifying the output is 'structure without body text' and the scope variants (entire book or under an address). This goes beyond the annotations and helps the agent understand the tool's behavior. No contradiction with 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?
The description is extremely concise: two short sentences. The first states the core action and scope, the second gives a directive. There is no filler or redundancy. Every sentence carries purpose, and the key usage hint is front-loaded. This is an optimal structure for quick comprehension.
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 5 parameters and no output schema, the description is quite incomplete. It covers the overall purpose and when to use, but provides no information about how to configure depth, scope, response_format, max_chars, or what 'kind' means. Since the schema is not self-explanatory (variable types and defaults), the tool definition is missing essential details for correct invocation. The annotations help, but they don't fill in parameter semantics. A more complete description would at least hint at how parameters affect the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. The description does not mention any of the five parameters (kind, depth, scope, max_chars, response_format) or their meanings. An agent looking at the schema alone would see defaults and enums but not what they control. The description provides zero parameter semantics, forcing the agent to guess. This is a critical gap.
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 returns the structure of a book or a section under an address, without body text. It mentions the scope ('entire book or under one address') and the content ('structure without body'), which makes the purpose specific. It does not explicitly differentiate from sibling tools like 'find' or 'get', but the phrase 'first step of broad exploration' gives a hint that this is for high-level navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit usage directive: 'Always use as the first step of broad exploration.' This provides clear context for when to invoke the tool. However, it does not mention when NOT to use it or suggest any alternative tools, so it lacks exclusionary guidance. Still, it gives a solid usage context, scoring a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description confirms read-only without contradiction. The description adds genuine value beyond annotations by disclosing row limits and an execution budget, which are not visible in the structured fields. It does not contradict any annotation.
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, front-loaded sentence that states the core action first, followed by the key constraints. It has no filler or redundant phrasing. Slightly dense in Korean but well-ordered and efficient.
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 an output schema, so return values need not be described. The description covers read-only semantics, statement type restriction, row limits, and execution budget. The main gap is the undocumented params parameter — an agent cannot reliably know how to use the third argument based on either the schema or 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 0%, so the description must compensate. It provides partial semantics: 'single SELECT/WITH' constrains the required sql parameter, and 'row limit' loosely maps to the limit parameter. However, the params object parameter (default null) is completely unexplained, leaving it ambiguous whether it binds query parameters or something else. With 3 parameters and zero schema coverage, coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('performs') and resource ('a single SELECT/WITH SQL') with explicit constraints (read-only, row-limited, budgeted). It implicitly differentiates from sibling tools by positioning itself as the escape hatch 'for analyses difficult to solve with hand-crafted tools,' though it doesn't name a specific sibling it replaces.
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 context is implied only — the agent can infer to use this when the hand-crafted sibling tools (check, find, get, etc.) are insufficient. However, no explicit when-not-to-use conditions are given, no sibling tools are named, and the phrasing 'difficult to solve with hand-crafted tools' leaves the exact boundary vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral trait: it is a local search (no external embedding API calls), which indicates performance and privacy characteristics. It also mentions the retrieval methods (BM25, dense, RRF), giving insight into how results are ranked. This goes beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the resource and method. It contains no redundant filler and gets straight to the point. Every word earns its place.
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 8 parameters, no output schema, and zero parameter descriptions, the context provided is insufficient. The description does not explain the meaning of tags, kinds, time-as-of semantics, limits, or response formats. An agent would be guessing about how to use these options correctly. The description is far too sparse 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It implicitly connects 'mode' to the three search methods (lexical, semantic, hybrid) but does not explicitly name the mode parameter or explain any of the other seven parameters (tag, kind, as_of, limit, max_chars, response_format). The description only addresses the core query resource, leaving the rest of the parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching title, alias, summary, and evidence text via BM25, dense, or RRF. It also explicitly notes that it does not call external embedding APIs, which helps distinguish it from potential alternatives. The verb 'search' and the listed resources make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is the search tool among the siblings (e.g., 'get', 'query', 'trace'), but it does not provide explicit guidance on when to use this tool versus others, nor does it mention when not to use it. There are no exclusions or alternative recommendations. The user must infer that this is the primary search mechanism.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the operation is a proposal and does not mutate the live graph, which is more specific than the non-destructive hint. It also implies a write operation (readOnlyHint=false) by saying 'records,' which is consistent. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The purpose is front-loaded in the first sentence, and the key behavioral note (no live graph change) is in the second. No redundant information, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, 4 required, nested ops objects), the description leaves significant gaps: it fails to explain parameter semantics, the relationship to commit, or the meaning of the output (though output schema exists). An agent would struggle to correctly invoke this tool without additional context on required fields like read_set and ops.
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 0%, so the description must compensate for explaining parameters. It only vaguely mentions 'non-empty read_set' and 'idempotency key' but does not explain what they mean, how they relate to the schema's fields, or what ops expects. With 8 parameters and 4 required, this is insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records operations as a change proposal and explicitly notes it does not alter the live graph, distinguishing it from commit. The verb '기록합니다' (records) and resource 'change proposal' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'this call alone does not change the live graph,' suggesting that actual changes require another step (likely commit). However, it does not explicitly name alternatives or specify when to use this tool versus siblings like commit. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it specifies that paths are 'bounded' and 'hard-edge' and that relationship type, depth, and number of paths can be limited. This clarifies the scope and behavior beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists the key constraints. There is no wasted wording; it is appropriately concise for the level of detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters with no schema descriptions and the tool's non-trivial behavior (bounded, hard-edge), the description does not fully explain critical details like what 'hard-edge' means, how 'to' null affects behavior, or what the output structure looks like (though output schema exists). The description covers the main idea but leaves gaps that an agent might need clarified.
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 0%, so the description carries the burden of explaining parameters. It mentions relationship type (via), depth (max_depth), and number of paths (k), and implies from-to via the purpose. However, it does not explicitly map these to parameter names or explain defaults or null behavior, leaving some ambiguity.
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 returns bounded hard-edge paths from one node to a specific target or narrative device, and mentions limiting relationship type, depth, and number of paths. It is specific about the action (tracing paths) and resource (nodes), but does not explicitly differentiate from sibling tools like neighborhood or find, though the purpose is fairly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for path tracing with constraints, but does not explicitly state when to use this tool over alternatives. It says 'you can limit relationship type, depth, and number of paths,' which gives context but no direct guidance on selection. The usage is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect disclosure. The description adds that it returns specific schema categories (nodes, edges, tags, rules), which goes beyond annotations. It doesn't mention error behavior or rate limits, but for a read-only metadata tool, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the tool's output and purpose. No wasted words, and the 'don't guess' imperative adds actionable value in the second clause. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations cover safety, the description omits key parameter behaviors (max_chars truncation, response_format verbosity) and doesn't describe the output structure (though no output schema exists). The tool is simple enough that an agent might infer some things, but the lack of parameter documentation for a 0% coverage schema makes it incomplete.
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 0%, so the description must compensate. It only implicitly explains the 'section' parameter by listing its enum values (node types, edges, tags, rules). 'max_chars' and 'response_format' are left completely unexplained. This is a significant gap given the coverage is zero.
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 specifies exactly what the tool returns ('node types, edges, tags, diagnostic rules') and frames it as the authoritative schema source ('don't guess, verify with this tool'). This clearly distinguishes it from sibling tools like 'query' or 'find' which operate on data rather than schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'don't guess the schema; verify with this tool' provides a clear directive on when to use it (whenever schema knowledge is needed) and implies it is the correct alternative to guessing or using other tools for schema discovery. It doesn't explicitly exclude other tools, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the key nuance that these are '근사치' (approximate) values and mentions the eligible-status filter, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences with no redundancy. It immediately states the core query and the primary filter option, making efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose and one usage scenario, it leaves several parameters unexplained and does not define the domain-specific fields (F-T-P, S-Eff, delta-Coh). The output schema exists, but the agent lacks enough context to choose parameter values with confidence.
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 0%, so the description must explain parameters. It only hints at the 'status' parameter (eligible status filtering) and ignores the other four (sort, as_of, max_chars, response_format). The agent cannot infer the intended values from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '조회합니다' (queries), the resource '복선의 F-T-P, 상태, 부채, S-Eff, delta-Coh 근사치' (foreshadowing's approximations), and adds a filtering condition. It specifies a unique scope that distinguishes it from sibling tools like 'get' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: '집필 전에' (before writing) and the ability to filter eligible status. However, it does not explicitly mention alternative tools or conditions for when not to use it, leaving some inference to the agent.
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:

[![storyai MCP server](https://glama.ai/mcp/servers/jedikim/storyai/badges/card.svg)](https://glama.ai/mcp/servers/jedikim/storyai)

Score Badge

Copy to your README.md:

[![storyai MCP server](https://glama.ai/mcp/servers/jedikim/storyai/badges/score.svg)](https://glama.ai/mcp/servers/jedikim/storyai)

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/jedikim/storyai'

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