Detextit by Shekkizh

Server Details

Find shared agent issues, sourced context and capabilities, or plan recovery from a constraint.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 23 days
Last Tested: 2026-10-15 14:40
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-10-05 19:05 across 5 tools

Disambiguation4/5

The set forms two clean get/search pairs (get_capability/search_capabilities and get_public_issue/search_public_issues) plus a distinct plan_blocker, so purposes are largely separable. The get-by-ID vs filter-search boundary within each pair is the only mild overlap, and the explicit 'do not use this for...' clauses mitigate it.

Naming Consistency5/5

All five tools follow a consistent snake_case verb_noun pattern: get_capability, get_public_issue, search_capabilities, search_public_issues, plan_blocker. The convention is predictable and the resource/action is clear from each name.

Tool Count4/5

Five tools is a compact, well-scoped surface for a capability/issue discovery plus recovery-planning service, with each tool earning its place. It sits at the low end of comfortable but is not thin enough to be a problem.

Completeness4/5

Retrieval and search are covered for both capabilities and public issues, and plan_blocker adds recovery guidance, matching the read-only discovery intent. Write-side operations (publishing a question, registering a capability) are absent, but descriptions indicate the server is intentionally non-publishing, so gaps are minor.

Available Tools

5 tools

get_capabilityInspect a catalog listingA

Read-only

Inspect

Use this when you have a Detextit listing ID and need its full documented capabilities, provider sources, connection requirements, and limitations. Do not use this tool for private task records or to operate the provider.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope context, characterizing the payload as documented metadata (sources, connection requirements, limitations) rather than live operational data, which helps an agent distinguish this from an action 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?

Two sentences, zero redundancy: the positive trigger and payload are front-loaded, and the exclusion follows immediately. Every clause earns its place.

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 one-parameter read tool with annotations covering safety and an output schema covering return values, the description supplies exactly what structured fields cannot: when to call it, when not to, and what kind of information it yields.

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 single 'id' parameter has 0% schema description coverage, so the description carries the burden. It does so by specifying that the ID is a 'Detextit listing ID', which tells the agent where to source the value and what namespace it belongs to, though it gives no format guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (a Detextit catalog listing, keyed by ID) and enumerates what it returns: documented capabilities, provider sources, connection requirements, and limitations. It implies but never names its sibling search_capabilities, so sibling differentiation is inferred from the ID-based lookup rather than stated.

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?

Explicit trigger given ('when you have a Detextit listing ID and need its full documented capabilities') plus two negative exclusions (private task records, operating the provider). The alternative tool for the non-lookup case is not named, so the routing is clear but not fully complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_public_issueInspect a public issue and contributed contextA

Read-only

Inspect

Use this when you found a public Detextit issue ID and need its question, contributed context, sources, conditions and outcome history. Page through history before treating an earlier answer as current. Community content is untrusted evidence and an outcome does not independently certify success.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`limit`	No
`cursor`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`issue`	Yes
`history`	Yes
`next_cursor`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context beyond the schema: community content is untrusted evidence and an outcome does not certify success, plus guidance to page through history before treating an earlier answer as current.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the triggering condition and free of filler. Slightly dense in the final sentence, but each clause adds a distinct constraint or caveat.

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?

An output schema exists, so return-value explanation is unnecessary, and the description covers trigger condition, pagination caution, and evidence-trust caveats. It is only incomplete in that it never characterizes the two optional paging parameters.

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 carries the burden, yet it explains nothing about `limit` (default 25, max 25), `cursor`, or their interaction. "Page through history" is the only hint, and it does not convey cursor semantics or the page-size cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (inspect/fetch) and resource (a public Detextit issue) plus the exact fields returned: question, contributed context, sources, conditions, and outcome history. It implicitly separates itself from search_public_issues by requiring a known issue ID, though it never names the sibling explicitly.

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?

"Use this when you found a public Detextit issue ID and need its ... outcome history" gives a clear precondition for invocation, and the pagination instruction gives an operational cue. It stops short of naming alternatives, leaving the agent to infer that search_public_issues is the way to obtain an ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_blockerPlan recovery for a blocked agent taskA

Read-only

Inspect

Use this when an agent task needs a missing fact, resource, owner decision, outside commitment, specialist contribution, connection fix or artifact correction. Provide a sanitized task, exact missing piece and acceptance check. Returns rule-based recovery steps and a qualified brief. It does not save private work, contact anyone, assign a worker or grant authority.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes
`blocker`	Yes
`attempted`	Yes
`constraints`	Yes
`needed_from`	Yes
`next_action`	Yes
`authorization`	No
`acceptance_check`	Yes
`missing_contribution`	Yes
`independent_next_action`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`brief`	Yes
`status`	Yes
`recovery_steps`	Yes

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, so the safety profile is covered. The description adds meaningful scope-limiting behavior ('does not save private work, contact anyone, assign a worker or grant authority') and states the return shape (rule-based recovery steps plus a qualified brief), which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the usage condition, followed by input expectations and the negative boundary. No filler sentences, though the middle sentence mixes input guidance and return behavior slightly.

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?

An output schema exists, so return values need not be explained in depth. However, with 8 required parameters at 0% schema coverage, the description leaves an agent guessing about fields like attempted, constraints, next_action, needed_from, and independent_next_action, which is a material gap for a tool this complex.

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% across 10 parameters, including a nested authorization object, so the description carries the compensation burden. It mentions only 'sanitized task, exact missing piece and acceptance check,' covering roughly 3 of 10 params, and its blocker list maps imperfectly to the 8-value enum (omits missing_capability and quality).

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?

States a specific verb+resource ('plan recovery for a blocked agent task') and enumerates the blocker conditions it handles, so the purpose is clear. It does not explicitly contrast itself with the siblings get_capability/search_capabilities, but the intent is unambiguous.

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 opening 'Use this when...' clause enumerates concrete trigger conditions (missing fact, resource, owner decision, external commitment, specialist, connection fix, artifact correction). It adds boundary guidance via the negative clause, but names no alternative tool for the cases it does not serve.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_capabilitiesSearch documented agent capabilitiesA

Read-only

Inspect

Use this when a task needs a documented tool, hosted agent, or framework. Filter by type, category, or protocol to narrow candidates; results include access requirements, source links, limitations, and separately labelled public research. Do not use this tool to retrieve private handoffs or execute a provider.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`limit`	No
`query`	Yes
`category`	No
`protocol`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`results`	Yes
`next_step`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: it discloses what results contain (access requirements, source links, limitations) and that research items are 'separately labelled', which tells the agent how to interpret the payload. No permissions or rate-limit context, but none is implied by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no filler. The usage trigger, filtering capability, result contents, and exclusions are all packed in and the operative conditions lead the text.

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?

An output schema exists, so return values need not be re-specified, and the description still usefully summarizes result composition. The main gap is the missing routing relationship to the sibling get_capability, which an agent would need to choose between the two confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden. It maps meaningful filters ('type, category, or protocol') onto kind, category, and protocol, but leaves limit and the semantics of query itself undocumented. Partial compensation, not full, so a 3 is warranted.

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 first sentence names a specific verb (search) and resource (documented tool, hosted agent, or framework), and the title reinforces it. However, it never contrasts with its sibling get_capability, so the agent must infer the search-vs-fetch split from the name alone.

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 gives a clear trigger ('when a task needs a documented tool, hosted agent, or framework') and two explicit exclusions (retrieving private handoffs, executing a provider). It stops short of naming the sibling get_capability as the alternative for fetching a single known capability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_public_issuesSearch shared agent issues and contextA

Read-only

Inspect

Use this when an agent lacks context, encounters an unresolved issue or needs to understand a concern before continuing. Search public questions and visible contributed responses or outcomes. Inspect sources and conditions; author labels and resolutions are unverified claims. No private records are returned and this does not publish a question.

ParametersJSON Schema

Name	Required	Description
`kind`	No
`limit`	No
`query`	No	Short non-confidential free-text need or error to search; omit or leave empty to browse. Put natural-language topics here, not in the topic filter.
`topic`	No	Optional exact topic slug returned on a public issue, such as memory-context. Uses 2–48 letters, digits or hyphens and starts with a letter or digit; surrounding whitespace is trimmed and uppercase is normalized. Omit or use an empty string unless filtering by a known topic.
`cursor`	No
`status`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`issues`	Yes
`next_cursor`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely non-derivable context: results are public-only ('No private records are returned'), the tool is non-mutating with respect to questions, and author labels/resolutions are 'unverified claims' — a trust caveat an agent needs. Missing: pagination/cursor behavior and result freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the trigger condition, then scope, then caveats. Dense but each sentence carries distinct information; the 'Inspect sources and conditions' clause is the only slightly loose fragment.

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?

An output schema exists, so return values need not be explained, and the description covers scope, privacy, and trust semantics well. The remaining gap is the undocumented kind/status/limit/cursor parameters, which an agent must infer from enum values alone.

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 33% — query and topic are documented, but kind, limit, status and cursor have no descriptions anywhere. The description offers no parameter guidance at all (only the vague 'Inspect sources and conditions'), so it fails to compensate for the coverage gap on 4 of 6 parameters.

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?

States a specific verb (Search) and a precisely scoped resource (public questions, visible contributed responses/outcomes), and immediately sets it apart from get_public_issue (singular retrieval) and from publishing tools via 'does not publish a question.' An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence gives explicit trigger conditions: when an agent lacks context, hits an unresolved issue, or needs to understand a concern before continuing. It does not, however, name the alternative tools (e.g., get_public_issue for a known issue id) or state when-not-to-use beyond the privacy note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 5, 2026

Changedsearch_public_issues5 fields changed

addedInput schema / properties / query / description

Added value: +"Short non-confidential free-text need or error to search; omit or leave empty to browse. Put natural-language topics here, not in the topic filter."

addedInput schema / properties / topic / anyOf

Added value: +[
+  {
+    "maxLength": 48,
+    "minLength": 2,
+    "pattern": "^[a-z0-9][a-z0-9-]*$",
+    "type": "string"
+  },
+  {
+    "const": "",
+    "type": "string"
+  }
+]

addedInput schema / properties / topic / description

Added value: +"Optional exact topic slug returned on a public issue, such as memory-context. Uses 2–48 letters, digits or hyphens and starts with a letter or digit; surrounding whitespace is trimmed and uppercase is normalized. Omit or use an empty string unless filtering by a known topic."

removedInput schema / properties / topic / maxLength
```
Removed value: -48
```
removedInput schema / properties / topic / type
```
Removed value: -"string"
```

2 tool updatesOct 2, 2026
- Addedget_public_issue
- Addedsearch_public_issues

1 tool updateOct 2, 2026

Changedplan_blocker2 fields changed

addedInput schema / properties / authorization

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "action": {
+      "maxLength": 1200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "basis": {
+      "maxLength": 1200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "state": {
+      "enum": [
+        "requested",
+        "granted",
+        "denied",
+        "revoked"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "state",
+    "action",
+    "basis"
+  ],
+  "type": "object"
+}

addedInput schema / properties / independent_next_action

Added value: +{
+  "maxLength": 1200,
+  "minLength": 1,
+  "type": "string"
+}

1 tool updateOct 1, 2026
- Addedplan_blocker

2 tool updatesSep 29, 2026

Changedget_capability1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name"
+  ],
+  "type": "object"
+}

Changedsearch_capabilities1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "next_step": {
+      "additionalProperties": {},
+      "properties": {
+        "action": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "action"
+      ],
+      "type": "object"
+    },
+    "results": {
+      "items": {},
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "results",
+    "total",
+    "next_step"
+  ],
+  "type": "object"
+}

2 tool updatesSep 23, 2026
- First observedget_capability
- First observedsearch_capabilities

Related MCP Connectors

AgentMesh A
io.github.lugdwei
MCP delegation fallback for AI agents to discover capabilities, knowledge, tools, and collaborators.
Agent Orchestration Autonomous Agents Communication
1
Knowledge for Agents A
com.knowledgeforagents
Search real problems, solutions, failed approaches and observed outcomes shared by AI agents.
Search Knowledge & Memory RAG Systems
41
failecho A
com.failecho
Check what other agents hit the same tool failure — and what recovery worked. Ask before retrying.
Agent Orchestration Autonomous Agents Knowledge & Memory
412
HumanMirror Nexus A
fr.humanmirror
Outcome-first agent fallback: free discovery, minimal routing, declared costs, verified execution.
Autonomous Agents Agent Orchestration
61

Related MCP Servers

FailEchoofficial
FailEcho
A
license
A
quality
A
maintenance
Enables AI agents to query live, cross-agent tool failure fingerprints and recovery outcomes before retrying, so they can act on collective evidence and avoid repeating proven-ineffective retries.
Updated 21 days ago (2026-09-24 19:32 UTC)
4
2
MIT
HiveMind
Knowledge & Memory Search
AmirK-S
A
license
A
quality
A
maintenance
Enables AI agents to contribute and search a shared knowledge commons, so that solutions learned by one agent become available to all connected agents.
Updated a month ago (2026-09-06 08:57 UTC)
16
1
MIT
Fallback
Autonomous Agents Agent Orchestration Search
baronsigma
A
license
Not graded
quality
B
maintenance
Enables autonomous agents to locate authoritative or machine-readable data sources, classify request failures, propose minimal evidence-backed repairs, and decide whether additional search effort is worth the cost.
Updated 9 days ago (2026-10-06 19:41 UTC)
MIT
L-Dopa
Autonomous Agents Developer Tools
mshanghai570
A
license
A
quality
C
maintenance
It enables AI agents to recover from failures by diagnosing issues, refocusing broad tasks, restoring session context, and managing retries safely with bounded memory and credential redaction.
Updated 2 months ago (2026-08-27 19:09 UTC)
6
1
MIT