threadline-core

by richardoros

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.2.0
Disambiguation5/5
Each tool targets a distinct resource and action: sessions, events, memory, loops, decisions, traps, findings, and evidence. Even the finding lifecycle tools (propose/confirm/resolve/dismiss) are clearly differentiated by their gating rules and effects.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., start_session, get_open_loops, mark_decision_outcome). Minor deviations like 'get_known_traps' are still readable and fit the pattern.
Tool Count4/5
17 tools is slightly above the typical 3-15 range, but each tool earns its place given the broad domain (sessions, events, memory, state, loops, decisions, traps, findings, evidence). The count feels justified rather than bloated.
Completeness4/5
The set covers the full lifecycle for the core entities: sessions are started/ended, events are logged, loops can be listed/claimed/resolved, decisions can be queried and outcomes marked, findings progress from proposal to confirmation/resolution/dismissal, and evidence is retrievable. Minor gaps exist (no explicit create/delete for projects, no list_sessions), but agents can work around them.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions the return format (dict with keys) but does not describe side effects, such as whether the finding becomes permanently suppressed, if it can be reversed, or any authentication or rate-limit requirements. The 'gated' reference is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two short paragraphs plus a return format block). It front-loads the purpose in the first sentence. However, the return format could be integrated more elegantly, and the 'GATED' note could be slightly less cryptic.
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 3 parameters, no annotation coverage, and an output schema, the description is incomplete. It covers the basic purpose and return values but fails to document parameters or behavioral context. For a mutation tool that modifies state, this is a significant gap.
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 3 parameters (finding_id, reason, evidence_refs) with 0% schema description coverage. The description does not explain the meaning, purpose, or usage of any parameter other than implying that reason and evidence_refs are optional. The return format mentions only finding_id, but this is insufficient for proper invocation.
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 purpose: 'Dismiss a finding as invalid/irrelevant.' The verb 'dismiss' and the target 'finding' are specific, and the description distinguishes this from siblings like confirm_finding and resolve_finding by specifying the action context.
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 mentions that the tool is 'GATED exactly like confirm_finding,' which gives a hint about access or permission constraints. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to dismiss vs. confirm), nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions gating but does not elaborate on side effects, reversibility, or required permissions. Return keys are listed but behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, one for gating, and a bullet for return structure. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema covers return values, but the description lacks context on state transitions, usage boundaries vs. siblings, and behavioral details. Adequate for a simple tool but not comprehensive.
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 explanation of the parameters (finding_id, evidence_refs). It adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks a finding as resolved, referencing a specific condition (resolution_condition met) and notes it is gated like confirm_finding. However, it does not differentiate from sibling tools like dismiss_finding, which also changes status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when resolution_condition is met and references confirm_finding for gating, but does not explicitly state when to use this vs. alternatives or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions recording a 'session_ended' event, but does not describe side effects such as whether the session becomes read-only, if pending operations are cancelled, or any authentication/authorization requirements. For a lifecycle tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (27 words in the main sentence) and front-loaded with the essential purpose. It includes a return format section, which is helpful. There is no wasted content. However, it could be more structured by including parameter guidance in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and an output schema. The description explains the return values but not the parameters. For a tool that ends a session, it should inform the agent about the importance of providing a meaningful summary and the correct session_id. The sibling tools suggest a decision/evidence context, but the description does not integrate this. Overall, the description is incomplete for correct usage.
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 4 parameters with 0% description coverage, meaning the schema provides no documentation. The description does not compensate by explaining any parameter's purpose, format, or constraints. For example, 'summary' and 'session_id' are critical for correct invocation but are left undefined. The only hint is 'agent_name' defaulting to 'claude_code', but this is not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for ending a work session, with the verb 'close' and the context 'at the END of a work session'. It distinguishes from sibling 'start_session' by being the complementary action. The mention of recording a 'session_ended' event further clarifies its role.
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 explicitly says to call at the end of a work session, providing clear usage timing. It also explains the benefit ('so the next agent can see what was done'). However, it does not explicitly state when not to use it or mention alternatives, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the return format and states 'Newest first'. However, it does not explicitly state that the tool is read-only, idempotent, or has no side effects. The term 'Return' implies a read operation, but more direct transparency would be helpful.
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 fairly concise, with direct opening sentences and a structured Returns block. While effective, the Returns section could be slightly trimmed, but overall it is well-organized and front-loaded.
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 description adequately explains the output format, which is useful given an output schema exists. However, it omits documentation of the single required parameter, leaving a significant gap in completeness. It also does not discuss preconditions or prerequisites beyond the usage 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?
The description completely fails to mention or explain the required parameter 'project_key'. The input schema has 0% description coverage, and the description does not compensate, leaving the agent to infer its meaning from context. This is a critical gap.
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 returns decisions proven wrong on the project along with the corrected rule. It uses specific verbs ('Return', 'Read') and resource ('decisions proven wrong'). It distinguishes from sibling tools like 'get_decisions' and 'get_decision' by focusing on known mistakes.
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 explicitly advises to 'Read these BEFORE acting so you do not repeat a known mistake,' providing clear when-to-use guidance. It implies this tool should be used early in a session. It does not explicitly mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the outcome constraint and return format, but lacks details on side effects, idempotency, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, and the description uses clear structure with a list of outcomes and a rule. Some formatting could be streamlined, but it is efficient overall.
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 with no schema descriptions and no annotations, the description only partially covers the tool's usage. Optional parameters are unexplained, making it incomplete for an agent to use correctly without prior knowledge.
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%, so description must compensate. It explains 'outcome' values and mentions 'evidence_refs' in a rule, but does not describe other parameters like reason, severity, applies_to, corrected_rule.
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 the real-world outcome of a past decision, listing valid outcome values. It distinguishes from sibling tools focused on findings or reads.
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?
Provides usage context by explaining the required evidence_refs for certain outcomes. However, it does not explicitly state when to use this tool vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 returns a dict or error if not found, and lists output keys. It implies a read-only operation without side effects. However, it does not mention permissions, rate limits, or idempotency, which are minor omissions for a simple getter.
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—3 sentences that front-load the main action and return format. The structured 'Returns' section adds clarity without extra words. Every sentence serves a purpose.
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 a simple single parameter and an output schema exists, but the description fails to explain the 'decision_id' parameter or the error dict format. No guidance on sibling differentiation is given. For a tool with 0% schema coverage and no annotations, this leaves gaps in understanding.
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 does not define the 'decision_id' parameter (e.g., format, source, uniqueness). The parameter name is self-explanatory, but the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns a single decision with outcome detail or an error dict. The verb 'Return' and resource 'decision+outcome' clearly define the action. The singular form distinguishes it from the sibling 'get_decisions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific decision is needed, but it does not explicitly state when to use this tool over alternatives like 'get_decisions'. No 'when not to use' or comparison criteria are provided, leaving ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: it requires admissible evidence, rejects self-reference, and returns a dict with specific keys. This gives the agent a good understanding of the tool's constraints and output, though auth or destructiveness are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The additional details about evidence refs and return format are provided in a structured manner, though it could be more organized.
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 core purpose, return keys, and a key constraint, it lacks details on what happens if evidence is invalid, error scenarios, or how the tool fits into the broader workflow. Given no annotations or output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description partially compensates by explaining the format of 'evidence_refs' (must be '<kind>:<id>' strings). However, the 'loop_id' parameter is not elaborated beyond the schema, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Mark an open loop resolved' with a specific verb and resource. It distinguishes itself from siblings like 'resolve_finding' by focusing on open loops.
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 mentions that the tool is gated and requires admissible evidence, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives or what happens if conditions are not met.
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 provided, so description carries full burden. It explains the gating condition and return value, but lacks details on reversibility, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, with a structured Returns section. Could be slightly more organized, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (2 params, one required) and presence of output schema, the description covers the key gating condition and return format adequately, though error conditions are omitted.
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 description must compensate. It adds context for evidence_refs (gated requirement) but provides no extra meaning for finding_id beyond its name.
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 "Confirm" and the resource "proposed finding", and distinguishes from sibling tools like propose_finding, dismiss_finding, and resolve_finding.
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?
Provides explicit gated requirement about evidence_refs and what is rejected, but does not mention when not to use it or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it returns only bounded snippets, never full transcripts, and how bad refs are handled. It also reveals the return structure. Missing details like authentication requirements or whether it's read-only, but the provided behavioral traits are clear and sufficient.
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 reasonably concise, starting with the main purpose and then detailing return values. The docstring-style Returns section adds clarity but could be more integrated. Overall, it is well-structured and front-loaded with the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and an output schema, the description explains the main function, return structure, and error handling. However, it fails to describe `max_chars`, which is a key parameter, leaving a gap in completeness for an agent to use 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?
Schema description coverage is 0%, so the description must compensate. It explains the `refs` parameter format (`<kind>:<id>`) but does not mention `max_chars` at all. The return structure is described, but parameter semantics are incomplete, leaving the agent guessing about the second parameter.
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 resolves evidence refs to bounded content snippets, specifying the format `<kind>:<id>`. The verb 'resolve' and resource 'evidence refs' are specific, and it distinguishes itself from siblings like get_decision or search_memory by focusing on evidence references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use it ('never full transcript bodies') and explains error handling ('bad refs reported in unresolved without failing'). However, it does not explicitly name alternatives or state when to prefer this over 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?
Discloses key behavioral traits: returns durable lifecycle records only, no synthesis, specific included fields, return type (dict), and error condition (LookupError). With no annotations, this is strong coverage, though side effects and auth are not mentioned.
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?
Concise yet informative: first sentence gives purpose, followed by exclusions, inclusions, return format, and error. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are adequately described. The parameter is minimal and self-explanatory. Overall, the description covers essentials for a single-parameter read tool, though parameter explanation would improve completeness.
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?
Only parameter 'project_key' has no description in schema (0% coverage) and description does not explain it. The tool relies entirely on the parameter name for meaning, which is insufficient.
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 verb 'Return' and resource 'raw governed state for a project'. Explicitly distinguishes from siblings by listing exclusions (no synthesis, no LLM output) and inclusions (objective, open loops, etc.), making the tool's unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on what the tool returns and excludes, allowing inference of when to use it (comprehensive state) vs siblings (specific components). However, lacks explicit 'when to use' or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It explains return value (dict with session_id and project_key) and implied session grouping. However, it doesn't mention side effects like whether starting a second session without ending the first is safe.
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?
Short and front-loaded with the key instruction. Uses a bullet for return values. Could be slightly more structured but overall 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?
Given no annotations and 0% param coverage, description could be more complete. It covers return values but lacks details on error cases, idempotency, or prerequisites.
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 description must compensate. It does not explain parameters beyond mentioning project_key in return. Parameter names are self-explanatory but description adds no additional meaning.
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?
Description clearly states the tool's purpose: to be called at the beginning of each work session to obtain a session_id for grouping events. It distinguishes itself from siblings like 'end_session' and 'log_agent_event'.
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?
Explicitly says when to use (beginning of every session) and hints at context (pass session_id to log_agent_event). No explicit when-not-to-use or alternatives, but clear 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?
With no annotations, the description discloses that it returns only live decisions, the sort order, and the output keys. It does not mention destruction or auth, but for a read-only tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, clarifies 'Live', distinguishes from a sibling, and lists return keys. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple schema (1 param, list output), the description covers behavior, return keys, and differentiation from one sibling. It could address get_decision, but overall sufficient.
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% and the description does not add any semantics to the project_key parameter beyond the obvious. It does not explain formatting or constraints.
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 it returns LIVE decisions for a project, newest first, and defines 'Live' as statuses in (active, accepted, validated). It distinguishes from get_known_traps, which returns incorrect/reverted decisions.
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 explicitly directs agents to use get_known_traps for incorrect/reverted decisions, but does not mention other alternatives or conditions for not using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that proposals are safe (no destructive side effects), dedup behavior, and returns a dict with all keys. This provides clear behavioral expectations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and uses bullet points for key details. It is front-loaded with purpose. However, some redundancy could be trimmed (e.g., repeating severity values in table and text).
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 8 parameters (5 required), 0% schema coverage, and an output schema, the description explains the return values but does not fully explain all parameters. It covers the core concept well but lacks completeness for a complex tool with many parameters.
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 description must compensate. It defines allowed values for finding_class and severity but not for impact, category, statement, etc. This leaves gaps. More parameter context would improve the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Propose a gap or caveat finding.' It distinguishes from siblings like confirm_finding, dismiss_finding, and resolve_finding. The verb 'propose' and resource 'finding' are specific.
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 explains that proposing is free and not surfaced until confirmed, guiding when to use this tool. It lacks explicit when-not-to-use or alternatives, but the context of siblings implies assessment. The added context of fingerprint dedup is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses BM25 ranking, server-side limit clamping to 50, and the return format. However, it omits any mention of destructive actions or authorization needs, though those are likely not relevant for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points for parameters, and return format. It is concise, front-loading the purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (searching multiple memory types), the description covers what is searched, ranking, all parameters, and return format. The output schema is described in text, making it complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: query as natural-language string, project_key for restriction, limit with default and server-side clamp. This adds essential meaning missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full-text search across all stored memory' and lists specific memory types (events, decisions, open loops, daily notes, compiled context fragments). This distinguishes it from sibling tools like get_decisions or get_open_loops, which focus on single types.
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 broad searches across multiple memory types but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return values (including error case) and that the tool ingests and derives summary counts. While it doesn't detail side effects or authorization, it is sufficient for a logging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, bullet points, and a code block. It is appropriately sized for the tool's complexity, though slightly lengthy. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema (implied but not provided), and no nested objects, the description is complete. It covers purpose, usage, parameter format, and return values. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully with a detailed example JSON and explanation of the expected shape. It also describes the return values, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report a work event to Threadline' and 'Parse and ingest a single AgentEventIn JSON payload.' It uses a specific verb ('report') and resource ('work event'), and the purpose is distinct from sibling tools like 'start_session' or 'get_decisions'.
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?
A 'WHEN TO CALL' section provides explicit guidelines: at significant checkpoints, blockers, or deferrals. This helps the agent decide when to use this tool, though it does not explicitly mention when not to call or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers the critical contention rules: first claim wins, re-claim by the same owner is a no-op, and claiming another owner's loop raises an error with the current owner in the message. This gives the agent a complete picture of 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?
The description is compact and well-structured: a one-line core rule, followed by the essential behavioral details, then a clear return format. Every sentence conveys meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a concurrency-sensitive mutation tool, the description provides the key rules, error behavior, and return schema. It is complete enough for an agent to select and invoke this tool correctly alongside the related loop-management siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 'owner' and 'loop_id' through the claim logic, but the 'lane' parameter is never explained. Since schema description coverage is 0%, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Claim an open loop for an owner — FIRST CLAIM WINS,' which states a specific verb and resource. It clearly distinguishes this tool from siblings like get_open_loops and mark_open_loop_resolved by focusing on the claiming action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'The foreman and every agent must claim a loop BEFORE touching files.' It also clarifies the conditions under which a claim is valid and what happens on re-claim or conflict, giving the agent clear behavioral expectations for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the semantics of open loops, the ordering, the filter behaviors including the special 'unassigned' owner value and the claimable True/False mapping, and lists the exact return fields. This goes well beyond a basic restatement.
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 well-structured: a one-sentence summary, a short clarifying definition, a bulleted list of filters, and a return specification. It is concise yet comprehensive, with no wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of annotations, the description covers all necessary aspects: what it does, when to use it, how filters work, what data is returned. The presence of an output schema (even if not shown) is complemented by the explicit return keys. Sibling tools are clearly differentiated by operation type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 does so thoroughly by explaining each optional filter's meaning, providing an example for lane ('retention-b'), and clarifying the claimable boolean semantics. The special 'unassigned' value for owner is also documented. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return open loops for a project, oldest first' with a specific verb and resource. It also explains the concept of open loops and explicitly distinguishes ordering behavior. This sets it apart from sibling tools like mark_open_loop_resolved or assign_open_loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—listing open loops for a project—and explains the rationale for oldest-first ordering. It does not explicitly name alternatives or when not to use it, but the intent is unambiguous. This qualifies as clear context without exclusions.
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:

[![threadline-core MCP server](https://glama.ai/mcp/servers/richardoros/threadline-core/badges/card.svg)](https://glama.ai/mcp/servers/richardoros/threadline-core)

Score Badge

Copy to your README.md:

[![threadline-core MCP server](https://glama.ai/mcp/servers/richardoros/threadline-core/badges/score.svg)](https://glama.ai/mcp/servers/richardoros/threadline-core)

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/richardoros/threadline-core'

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