@skyphusion/common-thread-mcp

Official

by skyphusion-labs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource or action within the investigation lifecycle, seed management, ingest, attribution, and manifest verification. The async job polling pairs (ingest_apify_twitter/get_ingest_job, attribute/get_attribution_job) are clearly separated. No two tools have overlapping responsibilities.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (list_, create_, get_, update_, delete_, add_, remove_, verify_, debug_). Minor deviations include 'health', 'investigation_summary', and 'attribute', which lack the standard verb prefix or object, but overall the naming is predictable.
Tool Count3/5
23 tools is at the heavy end for a single server, covering a full investigation pipeline with ingest, attribution, and manifest verification. While each tool has a specific purpose, the sheer number may overwhelm agents and suggests some tools (e.g., debug_* utilities) could be split into a separate server.
Completeness4/5
The tool surface covers the core workflow: create investigation, manage seeds, ingest data, run attribution, view runs, retrieve packets, and verify manifests. Missing features like listing all investigations or updating seeds are minor and can be worked around.
Average 3.4/5 across 23 of 23 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 7, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Raw manifest breakdown' does not reveal whether the tool is read-only, what 'raw' entails, whether it returns large or sensitive data, or any side effects. This is a serious transparency gap, as the agent receives no safety or behavior cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of five words and lacks a complete sentence, omitting critical details. While concise in length, it fails to earn its place by providing meaningful guidance.
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 no output schema and no annotations, the description must explain the tool's behavior, return value, and use context. It does not do so. The schema covers parameters well, but the overall tool remains opaque. The description is inadequate for an agent to understand what to expect or when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema fully documents both parameters, including defaults and token format, achieving 100% coverage. The description itself adds no parameter semantics, but the baseline of 3 applies because the schema effectively explains the parameters. The description does not need to repeat what the schema already provides.
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 'Dev visibility: raw manifest breakdown' is a fragment lacking an explicit verb or action. It vaguely suggests the tool provides a raw manifest breakdown for developers, but does not clearly state what the tool does (e.g., retrieves, displays, lists). It also fails to distinguish itself from sibling tools like list_manifest or verify_manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description provides no context for appropriate use cases, prerequisites, or exclusions. It is a bare phrase with no directional information for an agent selecting among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. 'Dev visibility' implies a read-only diagnostic function, but the description does not state whether it is read-only, what data it returns, or any side effects. The 'not a methodology deliverable' note adds little clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is easy to parse and front-loads the purpose. It does not waste words, though it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a debugging tool with no output schema and sparse annotations, the description is too brief. It does not explain what the tool returns, how to interpret the comparison, or any prerequisites, making it insufficient for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters (access_token, investigation_id), so the baseline is 3. The description adds no additional meaning beyond the schema, but it does not need to since the schema is clear.
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 'Dev visibility: extractor vs manifest for the investigation' indicates the tool provides debugging insight into a comparison between extractor data and manifest data. It is not a tautology and hints at a diagnostic purpose, but it lacks a specific verb or resource to clearly distinguish it from sibling tools like debug_manifest or get_ingest_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The caveat 'not a methodology deliverable' is a negative statement but does not help an agent decide between debug_ingest and similar debugging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior, but it only states a listing action. It omits any detail about pagination, ordering, output format, permissions, or side effects, providing no additional behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler words, earning top marks for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide sufficient context about what 'signature records' are and what the response contains. The minimal description leaves too much unspecified, especially given the related manifest tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters and has 100% coverage, so the baseline applies. The description adds no extra meaning about parameter usage or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List') and resource ('manifest signature records'), making the primary function unambiguous. However, it does not differentiate from siblings like list_manifest or verify_manifest, and lacks scope details such as whether it lists all signatures or filtered by investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. There is no mention of prerequisites, context, or explicit exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only summary operation but does not explicitly state read-only behavior, authentication requirements, error conditions, or what the output structure looks like. For a tool with no output schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which aids conciseness, but it is a fragment rather than a complete sentence and omits critical information like return values and usage context. It is not zero-waste prose; it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, this description is incomplete. It does not explain whether the counts are returned as numbers, an object, or a formatted string, nor does it clarify the meaning of 'active' seeds. For such a simple tool, more detail is needed to be fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (access_token and investigation_id) are already documented in the schema. The description adds no additional parameter semantics, which aligns with the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing counts of active seeds and manifest artifacts. While it lacks an explicit verb like 'retrieve' or 'get', the noun phrase unambiguously signals a summary/read operation and distinguishes it from sibling investigation management and artifact tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_investigation or list_seeds. It does not mention context, prerequisites, or expected invocation scenarios, leaving the agent to infer usage from the tool name alone.
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 does not disclose behavioral traits such as whether the poll is read-only, what response codes are expected, or how to handle job completion. The mention of '202 response' gives context about job creation but not the polling behavior itself. The description adds minimal behavioral context beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action 'Poll async attribution job'. There is no filler or redundant content. It is appropriately minimal, though it could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description is very brief. It doesn't explain how to obtain a job_id, what the polling response looks like, or how to differentiate from the similar get_ingest_job. For a polling tool, this is incomplete guidance.
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?
The schema describes access_token and investigation_id but leaves the required job_id with only a type/minLength, no semantic description. The tool description does not mention or explain any parameters, so it fails to compensate for the uncovered job_id. With 67% schema coverage, the description adds no value to parameter understanding.
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 polls an async attribution job, using the specific verb 'poll' and the resource 'attribution job'. It differentiates from sibling get_ingest_job by specifying 'attribution', though it doesn't explicitly name alternatives. The phrase 'from attribute' is slightly awkward but doesn't undermine understanding.
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 after an attribute operation returns a 202 response (as indicated by the parenthetical), but it doesn't explicitly state when to use this tool versus alternative polling tools like get_ingest_job. No exclusions or alternative guidance are provided; the usage context is only implied, not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It only states 'List seed accounts for the investigation,' which implies a read-only operation but does not explicitly disclose side effects, required investigation context, or any constraints such as pagination or filtering behavior beyond the parameter name 'include_removed' in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that immediately states the tool's purpose. It is front-loaded and wastes no words, though it may be too sparse to fully support the agent in all use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits important context such as what a 'seed account' is, what 'the investigation' refers to, and what the tool returns. Given the tool has three optional parameters and no output schema, the description is under-specified and leaves the agent without a clear picture of the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (access_token, include_removed, investigation_id), so the schema already documents them. The description adds no additional meaning or parameter context beyond the schema, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List) and the resource (seed accounts) scoped to 'the investigation.' It is not a tautology and distinguishes from sibling list tools by naming 'seed accounts' as the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_features or add_seed/remove_seed. It does not state prerequisites, such as requiring an investigation, or scenarios where a different tool is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It implies a read-only verification action but does not explicitly state side effects, return values, failure modes, permission requirements, or any other behavioral context. This is a minimal disclosure that leaves the agent guessing about what happens during verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and to the point, though the brevity sacrifices necessary detail for other dimensions.
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 a clear purpose, the description is incomplete for effective use. It lacks any explanation of output, behavioral nuance, or differentiation from sibling tools like list_manifest and list_signatures. The schema covers parameters well, but the overall tool context is underdeveloped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having detailed descriptions including defaults and environment variable fallbacks. The description itself adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (verify) and the resource (manifest signatures) within an investigation context, making the primary purpose understandable. However, it does not differentiate from sibling tools like list_signatures or debug_manifest, which could also be used for related tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no contextual usage scenarios. It is a standalone sentence with no explicit or implicit guidance about appropriate use 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?
With no annotations available, the description must fully disclose behavioral traits. It only states the action 'List' without explaining the nature of manifest entries, return format, pagination, or any side effects. The absence of such details leaves the agent uncertain about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that starts with the verb and includes the key resource and scope. Every word is meaningful, with no redundancy or irrelevant 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?
The description is too sparse for a tool with no output schema. It does not indicate what the returned list contains (e.g., entry names, hashes, timestamps) or how the result relates to the investigation. The lack of return value information leaves the tool contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters, so the description does not need to add parameter details. The baseline for high schema coverage is 3, and the description offers no additional semantics 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 lists archive manifest entries for the investigation. The verb 'List' and noun 'archive manifest entries' are specific, and the scope 'for the investigation' distinguishes it from sibling tools like verify_manifest and debug_manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as verify_manifest or debug_manifest. There is no mention of preferred contexts, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a read operation ('List') but does not mention return format, pagination, authentication requirements beyond the schema, or any side effects, which are important for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the core purpose efficiently and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks contextual completeness. While the schema covers parameters, there is no output schema, no annotations, and no explanation of return values or relationship to sibling tools. The agent is left without enough context to fully understand what happens when the tool is invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description adds little value here. The baseline of 3 applies since the agent can fully understand parameters from the schema; the description does not clarify any additional nuances.
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 'List attribution runs (summaries) for the investigation' has a specific verb ('List'), resource ('attribution runs'), and scope ('for the investigation'). It clearly distinguishes from sibling tools like get_run (single run) and investigation_summary, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as get_run or investigation_summary. There are no explicit use cases, exclusions, or references to sibling tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions constraints like 'Active only' and a cap, but these are vague and do not explain side effects, permissions, reversibility, return values, or failure modes. For a mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with a clear verb. It communicates the core purpose and two key constraints efficiently. However, the phrase 'Active only' is ambiguous and could be more explicit, slightly reducing structural clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description leaves many gaps. It does not explain authentication, return behavior, error cases, or what happens when the cap is reached. The description alone is not sufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description only re-lists three of the required parameters (platform, handle, basis_statement) without adding new semantic details, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a seed account' with specific components (platform + handle + basis_statement). It also includes constraints ('Active only', 'Cap: MAX_SEED_ACCOUNTS') that further specify scope. This clearly distinguishes it from sibling tools like list_seeds and remove_seed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is used (adding seed accounts) but does not explicitly contrast with alternatives or state when not to use it. The 'Cap: MAX_SEED_ACCOUNTS' line hints at a limiting condition, but the guidance is minimal and not fully 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 provided, the description carries the transparency burden. It usefully discloses authentication requirements (BYOK) and the possible sync/async response modes (200 sync or 202 async jobId). However, it omits side effects, job lifecycle behavior, or what the returned data contains, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every phrase earns its place. It conveys the core action, auth precondition, and async behavior without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, this description is minimal but covers the essential entry point: what it does, a key prerequisite, and the two possible response modes. It lacks context on how to retrieve the async result (e.g., via get_attribution_job), what 'active seed pairs' means operationally, and any dependency on environment variables beyond the schema, leaving gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78%, so the schema already documents most parameters. The description adds value by clarifying the BYOK parameter relationship ('ai_gateway_url + anthropic_api_key or cf_aig_token'), which is not fully explicit in the schema. It does not explain account_filter, randomization_seed, or skip_triage beyond their schema descriptions, so the added semantic value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run attribution') and the resource ('active seed pairs'). It distinguishes itself from sibling tools like get_attribution_job by signaling that this tool initiates attribution rather than retrieves an existing job. However, 'active seed pairs' is somewhat jargon-heavy and 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a key precondition (BYOK on public host) but provides no explicit guidance on when to choose this tool over siblings like get_attribution_job or list_runs. It does not exclude any use cases or state when not to use it, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description relies on the word 'Fetch' to imply a read-only operation, which is a basic safety signal. However, it does not disclose potential error behavior, authentication requirements, or whether the operation is idempotent, limiting its transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function without any redundant information. It is well-structured and easy to parse, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description is minimally sufficient but lacks detail about what 'metadata' includes or what the return value looks like. It could be more complete by clarifying the response structure or typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (access_token and investigation_id), and the description adds no additional semantic information beyond the schema. With 100% schema coverage, the baseline score of 3 applies.
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 fetches investigation metadata and practitioner metadata using the specific verb 'Fetch' and identifies the resource. However, it does not differentiate itself from sibling tools like investigation_summary or get_run, which could also return similar data.
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 compared to alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate, leaving the agent to infer usage from the name alone.
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 needs to disclose behavioral traits, but it only says 'Query' without explaining default behavior, filter combinations, pagination, or permissions. It does not contradict annotations, but offers minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded, and contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and no annotations, this one-liner is severely incomplete. It fails to explain what the query returns, how filters interact, what include_provenance does, or how account_a/account_b differ from account.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, so the description must compensate. It adds meaning to the 'scope' parameter by listing account/pair/event, but ignores all other parameters, leaving parameter semantics underdefined.
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 'Query' and the resource 'extracted features', with a parenthetical specifying the feature types (account / pair / event). This distinctly separates it from siblings like list_seeds and list_runs.
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 phrase 'after ingest+extract' provides clear contextual timing for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output format behavior (JSON, markdown, base64 PDF) and a prerequisite (PDF worker), which is valuable. However, it does not mention the redaction behavior controlled by 'redact' and 'redact_accounts' parameters, nor does it state whether the operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. Two sentences deliver the core purpose, default behavior, and parameter-specific outputs without any wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters and no output schema, the description covers the main usage scenarios (default run, formats) but omits important contextual details such as redaction behavior, practitioner parameter, and what the packet contains. This makes it adequate but not fully complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic value beyond the schema for key parameters: 'run_id' is explained as selecting a specific run versus default latest, and 'format' is clearly tied to return types (JSON, markdown, base64 PDF). This meaningfully supplements the 57% schema coverage, though not all parameters are addressed.
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 retrieves an 'Evidence packet' and explains its default behavior ('Default JSON for latest run') and how to get a specific one. It distinguishes from siblings like get_run by focusing on the packet resource, though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives practical usage guidance for selecting run_id and format options, including the PDF worker requirement. However, it does not explicitly state when to prefer this tool over siblings or any exclusions, leaving the when-to-use nuanced to inference.
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 carries the full burden of disclosing behavioral traits. It explicitly states 'soft-delete' (not a permanent delete) and 'audit row retained' (preserves an audit trail), which are meaningful details beyond what the name suggests. However, it does not mention permissions, reversibility, or effects on related data beyond the audit row, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that conveys the core action and its key behavioral consequence. Every word earns its place, and there is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the operation is conceptually simple, the tool has five parameters with only 40% schema coverage and no output schema. The description does not explain the purpose of the parameters, prerequisites, or what the response contains, leaving significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (two of five parameters have descriptions), and the tool description itself does not explain any parameters. It fails to clarify the required 'platform' and 'account' parameters or the optional 'removed_reason'. Since the description does not compensate for the low schema coverage, parameter semantics are weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('soft-delete') and identifies the resource ('seed') with an explicit scope ('active'), making the tool's purpose unambiguous. It clearly distinguishes from sibling tools like add_seed and list_seeds by focusing on deletion behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'soft-delete an active seed' implies the appropriate context (when you want to remove a seed without permanently destroying it), but there is no explicit guidance on when not to use it or how it compares to alternatives like hard deletion or other removal tools. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: 'Ingest and attribution disabled; data stays readable with the token.' This goes beyond the simple 'mark read-only' and is valuable. However, it does not mention reversibility (can it be unsealed?), permission requirements, or any side effects on existing tokens. This leaves notable behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and then providing concise behavioral details. Every word earns its place, with no fluff or repetition. It is an excellent model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with no output schema, the description covers the main effect (what becomes disabled/enabled) but omits important context like reversibility, error conditions, or what the response indicates. Given the absence of annotations and output schema, a bit more detail about the result and any prerequisites would make it complete enough for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The tool description adds no extra parameter-specific details beyond the schema. The mention of 'with the token' relates to access_token but does not enrich the schema's existing explanation. Baseline of 3 applies because the schema does the heavy lifting.
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 investigation read-only (sealed)') and the resource (investigation). It also distinguishes from sibling tools by specifying the consequences: 'Ingest and attribution disabled; data stays readable with the token.' This gives a specific verb+resource and unique behavior, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: sealing an investigation to disable further ingest/attribution while keeping it readable. However, it does not explicitly state when to prefer this over alternatives (e.g., delete_investigation) or provide any exclusion criteria. The usage is inferable but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the PATCH method and active-only constraint, but does not explain side effects, return values, permission requirements, or consequences of partial updates. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the action and key constraint. The paper section references add a bit of noise but do not detract significantly from clarity.
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 that the schema fully documents all parameters and there is no output schema, the description sufficiently covers the core action and the active-only constraint for a simple metadata update tool. However, it leaves questions about failure modes and behavior on inactive investigations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the 4 parameters, including null-to-clear semantics for time_bounds and event details for triggering_events. The description adds minimal extra meaning beyond naming the two updatable fields, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'PATCH practitioner metadata' with specific fields (triggering_events and/or time_bounds) and paper references, making it distinct from sibling tools like seal_investigation or delete_investigation. The verb+resource combination is precise.
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 notes 'Active only,' which provides a context for when this tool can be used. However, it does not explicitly mention alternatives or when not to use it, such as for sealed or deleted investigations. It implies usage through the PATCH action but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is parsed and lists the categories, which is useful behavioral context. However, it does not mention potential errors, authentication, or other behavioral aspects like what happens if the run is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and output content.
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 no output schema, the description does a good job of listing the key output components (claims, alternatives, declined pairs, triage). It covers the primary need for an agent deciding whether to call this tool, though it lacks detail on return format or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema documents access_token and investigation_id. The tool description itself adds no parameter-specific meaning beyond the schema. run_id is self-explanatory from the tool name, but the description does not compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single attribution run and specifies the content of the parsed output (claims, alternatives, declined pairs, triage). This distinguishes it from sibling tools like list_runs (plural) and get_attribution_job (job vs run).
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 retrieving one specific run's parsed output, but does not explicitly state when to use this over list_runs or other alternatives, nor does it mention any exclusions. It provides minimal context, mostly implied by the word 'single'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read/poll operation ('poll') and the job source, but does not disclose behavior like whether it blocks, what happens on missing job, or safety guarantees. It conveys the basic operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and the key parameter. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple poll tool with a required job_id and no output schema, the description is mostly complete. It specifies the operation and source but could benefit from a hint about the response format or polling semantics. Overall, it is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds meaning by linking job_id to ingest_apify_twitter, clarifying that the job originates from that specific worker. This adds value beyond the schema, which lacks a description for job_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Poll ingest job status') with a specific resource ('ingest job') and method ('by job_id'). It distinguishes itself from sibling tools like get_attribution_job and get_run by specifying it polls ingest jobs from ingest_apify_twitter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to check the status of ingest jobs created by ingest_apify_twitter. It doesn't explicitly exclude alternatives, but the 'from ingest_apify_twitter' clause provides clear context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reveal meaningful behavior: side effects ('Archives + runs extractors'), asynchronous processing (returns jobId, requires polling), and a constraint ('Active only'). It does not cover failure modes or reversibility, but it provides more behavioral context than many tool descriptions.
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 just two sentences and front-loads the verb and object. Every phrase ('Archives + runs extractors', 'Returns jobId', 'Active only') is essential and free of filler.
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 absence of an output schema and annotations, the description covers the main flow: upload, side effects, response handle, polling, and a precondition. It is slightly incomplete because 'Active only' is terse and it does not address failure/error behavior, but overall it gives the agent enough to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (100% coverage), so the baseline is 3. The description only restates the items format ('array or {items|data}') without adding nuance about default token/investigation_id usage or parameter interplay, thus adding minimal 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 specific action ('Upload Apify Twitter export JSON'), specifies the input format, and distinguishes itself from siblings by outlining the asynchronous job flow ('Returns jobId; poll get_ingest_job until completed'). It also names the resource and expected side effects ('Archives + runs extractors').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage protocol: after uploading, poll get_ingest_job for completion, which explicitly indicates when to use the related polling tool. It also hints at a precondition with 'Active only', implying the investigation must be active. However, it does not explicitly state when to prefer this tool over other ingest/debug tools or exclude misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output (API URL, version, hosted-API notice) and the HTTP method/path, but does not explicitly state it is read-only or describe error behavior. This is adequate for a simple health check but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with 'Backend health check'. Every word adds value with no redundancy or filler.
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 zero-parameter health check with no output schema, the description is complete. It states the purpose and what it confirms, which is all that is needed for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The description adds the endpoint path 'GET /', which is meaningful context beyond the empty schema. Baseline for 0 params is 4, and the description maintains that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a backend health check with a specific verb ('confirms') and resource (API URL, version, notice). It is distinct from all sibling tools, which focus on investigations, seeds, and ingestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying backend connectivity and API metadata. There are no similar sibling tools, so no explicit exclusions are needed. It lacks explicit 'when to use' phrasing but is clear in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, and it excels: it discloses that this is a hard delete, specifies which storage layers are affected (MySQL rows + R2 prefix), states what is retained (sha256 blobs), and identifies refusal conditions. This is substantial behavioral context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short, purposeful sentences. Each provides critical information: what is deleted, what is refused, and what is retained. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no output schema, the description covers the essential behavioral aspects: scope, storage layers, retention, and refusal cases. It could mention return values or error handling, but given the simplicity and the schema's parameter documentation, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions (access_token, investigation_id) and 100% coverage. The tool description adds no extra parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Hard-delete' with a specific resource ('ACTIVE investigation') and scope (MySQL rows + R2 prefix). It distinguishes from sibling tools by explicitly limiting to active investigations and mentioning sealed/archived refusal, which differentiates it from seal_investigation and other lifecycle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-not condition ('Sealed/archived refuse') and implies when-to-use (for active investigations). However, it does not name alternative tools or suggest what to do for sealed/archived cases, so it falls short of full guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: the access_token is returned exactly once and cannot be recovered, and encryption at rest uses a key derived from that token. This information is essential for the agent to handle the response correctly and warn about token loss.
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, each earning its place. The first states the core purpose; the second highlights the critical token behavior and encryption detail. No filler 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?
Despite the absence of an output schema and annotations, the description fully covers the essential context for a creation tool: what it does, the crucial return value (access_token), and an important security behavior (encryption at rest). For a create operation, this is sufficient and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with clear descriptions for id, name, and description. The tool description adds no additional parameter-level meaning, so a baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a new investigation,' using a specific verb and resource. It clearly distinguishes this tool from siblings like get_investigation, update_investigation_metadata, seal_investigation, and delete_investigation.
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 clearly indicates this is for creating a new investigation, which is obviously distinct from the update, get, and delete siblings. It does not explicitly list when-not-to-use or name alternative tools, but the creation context is unmistakable and the token warning implies this is a one-time setup action.
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:

[![common-thread-mcp MCP server](https://glama.ai/mcp/servers/skyphusion-labs/common-thread-mcp/badges/card.svg)](https://glama.ai/mcp/servers/skyphusion-labs/common-thread-mcp)

Score Badge

Copy to your README.md:

[![common-thread-mcp MCP server](https://glama.ai/mcp/servers/skyphusion-labs/common-thread-mcp/badges/score.svg)](https://glama.ai/mcp/servers/skyphusion-labs/common-thread-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/skyphusion-labs/common-thread-mcp'

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