heddle

Official

by foundryside-dev

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: v1.0.0
Disambiguation1/5
The tool set contains exact duplicates (e.g., changed and heddle_change_list, churn and heddle_entity_churn_count_get, etc.) with identical descriptions, making it impossible for an agent to distinguish between them. This severe overlap undermines any ability to reliably select the correct tool.
Naming Consistency1/5
Naming is chaotic: half the tools use short names (blast_radius, changed, churn, reverify, timeline) while the other half use a 'heddle_' prefix with different patterns (heddle_change_list, heddle_edge_snapshot_capture, etc.). Verbs are mixed (capture, changed, get) and no consistent verb_noun pattern is followed.
Tool Count3/5
The raw count of 12 tools is within a reasonable range, but half are duplicates, effectively reducing the unique tool count to 6. While not extreme, the duplication suggests poor scoping and undermines efficiency.
Completeness3/5
The set covers core operations like capturing snapshots, listing changes, getting churn/timeline/impact radius, but lacks update/delete or other lifecycle operations. The duplicates do not add new functionality, so coverage is adequate but not comprehensive.
Average 2.6/5 across 12 of 12 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 125 commits in the last 12 weeks
- Last stable release on June 24, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It hints at 'mandatory completeness+staleness' and 'NO_SNAPSHOT' being an honest answer, but does not explain what these mean or whether the tool is read-only, destructive, etc. Lacks essential 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse (2 sentences), but sacrifices clarity. Important information about behavior and parameters is omitted. Not efficient; it's under-specified.
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?
Given the complexity (10 params, nested objects, no schema descriptions, many siblings), the description fails to provide enough context for an agent to understand or use the tool correctly. Completely inadequate.
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 coverage is 0% with 10 parameters including complex nested objects. The description provides no explanations for any parameters (e.g., repo, rev_range, changed_refs, filters). Adding zero value beyond the schema.
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 it finds 'downstream affected entities from stored dated snapshots' but uses vague jargon like 'mandatory completeness+staleness' and 'NO_SNAPSHOT', making the purpose unclear. It does not effectively differentiate from siblings.
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 its many siblings (e.g., changed, heddle_impact_radius_get). No context about prerequisites 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?
With no annotations, the description must fully disclose behavior. It hints at two modes (normal and NO_SNAPSHOT) and mentions 'completeness+staleness', but lacks details on side effects, authorization requirements, rate limits, or output characteristics. It does not clarify if the tool is read-only.
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 very short (two sentences) and uses no fluff, but it is overly terse and includes jargon ('downstream affected entities', 'changed-set-only answer') that may confuse. It front-loads the core concept but lacks clarity.
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?
Given the complexity (10 parameters, nested objects, output schema), the description is severely insufficient. It does not explain parameters, output format, or how to switch between modes. It fails to provide a complete understanding of the tool.
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. It provides no information about any of the 10 parameters (repo, rev_range, etc.) or how to use them. The description only mentions high-level output modes without linking to parameter values.
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 mentions 'Downstream affected entities from stored dated snapshots' which gives a general idea of what the tool does, but lacks a clear verb and does not distinguish from siblings like 'blast_radius' or 'changed'. The term 'downstream affected entities' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'blast_radius' or 'heddle_change_list'. It mentions 'mandatory completeness+staleness' and 'NO_SNAPSHOT' mode, but does not explain the context or when each mode 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?
Annotations are absent, so the description must disclose behavioral traits. The cryptic phrase 'sibling enrichment is advisory and never gates; absence is explicit, never clean' provides unclear behavioral context. No mention of mutation, side effects, or authorization.
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 (two sentences), but the second sentence is confusing and adds little value. It is concise but not well-structured for clarity.
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?
Given the tool's complexity (12 parameters, nested objects, output schema, many siblings), the description is far too brief. It lacks parameter explanations, usage context, output description, and integration with sibling tools.
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%, and the description provides no information about any of the 12 parameters. This is a critical gap for an agent to invoke the tool correctly.
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 renders the agent worklist to recheck before claiming completion, but 'agent worklist' is undefined and there is no distinction from sibling tools like 'heddle_reverify_worklist_get'. The cryptic second sentence does not clarify the purpose.
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 sibling tools or when not to use it. The description does not address alternatives 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?
With no annotations, the description bears full responsibility for behavioral disclosure. While it mentions that sibling enrichment is optional and absence is explicit, it fails to state side effects, idempotency, authentication needs, or rate limits. The cryptic second sentence adds limited 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 concise (two sentences) but the second sentence is cryptic and may confuse rather than clarify. It could be restructured to front-load practical usage 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's complexity (12 params, many siblings, output schema), the description is incomplete. It does not explain the output, how the worklist relates to other heddle tools, or how to use parameters effectively.
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 input schema has 12 parameters with 0% description coverage in the schema, yet the description provides no explanation for any parameter. It does not mention 'repo', 'rev_range', or others, leaving the AI agent to guess their meaning.
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 'Render the agent worklist to recheck before claiming completion', which clearly identifies the tool's purpose: retrieving a worklist for verification. However, it does not differentiate from sibling tools like 'reverify' or others, and the term 'agent worklist' is not further clarified.
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 only states an internal behavioral property ('Sibling enrichment is advisory and never gates'), but offers no explicit when/when-not instructions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool only reports SEI resolution and not lineage, but it fails to mention ordering criteria, authentication needs, destructive potential, or pagination behavior. The lack of detail leaves significant behavioral ambiguity.
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 two sentences, concise and front-loaded with the primary purpose. However, it omits essential information about parameters and usage, making it too sparse. Conciseness is achieved 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?
Given 8 parameters (many nested) and a rich set of sibling tools, the description is inadequate. It does not explain entity_ref structure, filter semantics, sorting options, or pagination. The presence of an output schema does not compensate for the lack of input guidance.
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?
With 0% schema coverage, the description should explain parameters but does not. No parameter names or usage are mentioned. The only clue is 'for one entity ref' hinting at entity_ref, but repo, filters, sort, limit, cursor remain unexplained.
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 'Ordered change history for one entity ref,' which clearly indicates the tool provides a chronological list of changes for a single entity. It further distinguishes from siblings by noting that it only reports SEI resolution and never claims lineage, differentiating it from tools like blast_radius or heddle_impact_radius_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'for one entity ref' implies single-entity use, but there is no mention of when not to use it or which sibling tools are better suited for multi-entity or lineage queries.
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 full burden. It discloses that mutations are scoped to .weft/heddle state and mentions a server config for the loomweave command, but does not address idempotency, side effects, dry_run behavior, or other behavioral traits beyond the basic mutation claim.
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 sentences, directly stating purpose and a key constraint. No redundant information, but a slightly more structured format (e.g., bullet points for key behaviors) could improve scannability.
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 8 parameters, no annotations, and an output schema (unseen), the description is insufficient. It does not explain parameter usage, return values, or provide enough context for an agent to correctly invoke the tool without external knowledge.
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%, meaning no parameters are described in the schema. The description adds no information about parameters; it only mentions capturing edges without relating to any of the 8 parameters defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool captures 'dated loomweave edges' into a specific store and distinguishes from sibling tools by noting it only mutates .weft/heddle state. However, the term 'loomweave edges' is domain-specific and may be unclear to some agents.
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?
Description mentions that the tool never mutates a sibling repo, providing a hint about when not to use it, but it lacks explicit guidance on when to use this tool versus alternatives like 'capture_snapshot' or 'heddle_change_list'. No explicit when/when-not or alternative recommendations.
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?
Discloses that never-observed entities return 0, not an error, which is valuable. But it does not mention mutability, auth needs, rate limits, or specifics about the window parameter. Since annotations are absent, the description carries full burden and is only partially adequate.
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 concise sentences front-loaded with purpose. No wasted words, but could be expanded with important details without losing 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?
Given 7 parameters including a nested object, cursor, and sort fields, the description is insufficient. It fails to explain what 'SEIs' means, how the window parameter is structured, sort options, or pagination behavior.
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?
With 0% schema description coverage, the description adds no parameter-specific information beyond the general purpose. It mentions 'window' but does not explain its structure or the other 5 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?
Clearly states it counts change events per entity over an optional window and handles never-observed entities. However, it does not differentiate from similar siblings like 'changed' or 'heddle_entity_churn_count_get'.
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. No mention of prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions mutation scope and server config, but fails to disclose destructive potential, idempotency, or safety profiles like dry-run or idempotency_key. This is insufficient for an 8-parameter 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?
Three sentences efficiently convey the core purpose and scope without extraneous words. Could be slightly more structured, but it remains concise and front-loaded.
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?
Given the high parameter count (8), zero schema coverage, and no annotations, the description is severely incomplete. It lacks explanations of behavior under different modes, error states, side effects, and parameter interactions, leaving the agent underinformed.
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%, yet the description provides no explanations for any of the 8 parameters. The description adds zero value beyond the raw schema, leaving the agent without guidance on how to fill fields like repo, mode, or changed_refs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: capturing dated loomweave edges into heddle's local store. It also distinguishes from siblings by noting it mutates only .weft/heddle state and never a sibling repo.
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 local state mutation without affecting siblings, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusion criteria.
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?
Given no annotations, the description adds value by clarifying return value for unseen entities (0 not error). However, it lacks disclosure on idempotency, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and a key behavioral trait. No extraneous 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?
Despite having an output schema, the description is too minimal for a complex tool with 7 parameters, nested objects, and many siblings. Missing guidance on sorting, pagination, and how entity_refs is constructed.
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 has 7 parameters with 0% description coverage. The description only mentions 'optional window' without explaining any parameter structure or constraints, leaving the agent with no additional meaning beyond schema fields.
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 it is a per-entity change-event count with an optional window. It specifies a behavior for never-observed entities, but does not differentiate from sibling tools like 'churn' or 'heddle_change_list'.
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. No context on prerequisites or limitations beyond the brief behavior note.
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 present, so description carries full burden. It discloses a key behavioral trait: it only reports SEI resolution and never claims lineage. However, it does not mention whether the operation is read-only, requires authentication, has rate limits, or how pagination works.
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 concise sentences that front-load the purpose. No filler, but could be slightly more structured (e.g., listing key constraints).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex with 8 params including nested objects. The description fails to explain parameters or usage context, making it incomplete for effective agent use.
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 coverage is 0% with 8 parameters. Description only mentions 'entity ref' but does not explain any parameter's purpose, format, or constraints. This severely hinders correct invocation.
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?
Clearly states it provides 'ordered change history for one entity ref' – a specific verb and resource. Differentiates from sibling tools like 'timeline' and 'heddle_change_list' by focusing on a single entity with ordering and specific SEI resolution reporting.
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 siblings. The description only adds a behavioral note about SEI resolution and lineage, but does not indicate prerequisites, constraints, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially compensates by disclosing that it is local-only and may initialize state. However, it does not detail other behavioral traits such as permissions, side effects beyond initialization, or response format. More transparency is needed given the lack of 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 very concise: two sentences that front-load the purpose. Every sentence adds value without unnecessary 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?
Given the complexity (10 parameters, output schema), the description is incomplete. It lacks parameter details, output structure, and comprehensive behavior. It does not fully inform an AI agent about how to use the tool effectively.
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 has 10 parameters with 0% description coverage, and the description does not explain any parameters. It fails to add semantic meaning beyond parameter names. The description must compensate for low schema coverage but does not.
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 lists changed entities and retrieves next actions for reverify/impact. It identifies the resource (changed entities for an ingested repo) and the action (list and get next actions). It hints at differentiation from siblings like 'heddle_change_list' by mentioning 'ready-to-call reverify/impact next actions', but could be more explicit.
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 context ('Local-only; may initialize .weft/heddle state') but does not explicitly state when to use this tool versus alternatives like 'heddle_reverify_worklist_get' or 'reverify'. Usage 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?
With no annotations, the description must carry the burden. It mentions 'Local-only; may initialize .weft/heddle state' which is a behavioral trait. However, it does not disclose potential side effects like file writes or modifications, nor does it clarify what 'initialize' entails. More detail would be needed for a higher score.
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: first states the main action clearly, second adds important caveats (local-only, may initialize state). No unnecessary words, front-loaded, and efficiently conveys scope and constraints.
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 high complexity (10 params, nested objects, output schema), the description is minimal. It does not explain the parameters, output structure, pagination (cursor, limit), or sorting. The output schema exists but is not referenced. The description is insufficient for an agent to use this tool correctly.
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%, and the description does not explain any of the 10 parameters. It says nothing about 'repo', 'rev_range', 'filters', etc. This fails to add meaning beyond the schema, leaving the agent guessing.
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 it lists changed entities and provides next actions like reverify/impact. It distinguishes itself from siblings like 'changed' by mentioning reverify/impact next actions. However, it does not explicitly differentiate from other similar tools like 'heddle_reverify_worklist_get' or 'heddle_entity_churn_count_get', so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list changed entities and get next actions, but it does not specify when not to use it or provide alternatives among sibling tools. The context signal shows many heddle-related siblings, yet no guidance is given on choosing this over them.
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:

[![warpline MCP server](https://glama.ai/mcp/servers/foundryside-dev/warpline/badges/card.svg)](https://glama.ai/mcp/servers/foundryside-dev/warpline)

Score Badge

Copy to your README.md:

[![warpline MCP server](https://glama.ai/mcp/servers/foundryside-dev/warpline/badges/score.svg)](https://glama.ai/mcp/servers/foundryside-dev/warpline)

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/foundryside-dev/warpline'

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