Submit an async question to kapoost. Returns an ID. Rate-limited 5/hr/IP. Poll fetch_answer later — kapoost answers on his own schedule (minutes, hours, or days). ALWAYS set from to a stable name for yourself: with it, sending the same question again returns the answer instead of creating a duplicate, which is the reliable path when your runtime cannot keep the ID between sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | ||
| context | No | ||
| question | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / context / descriptionRemoved value: -"Optional: short reason why you're asking (e.g. piece slug, task)."Input schema / properties / from / descriptionRemoved value: -"Optional: agent identity (e.g. claude-code, gpt-4o). Max 64 chars."Input schema / properties / question / descriptionRemoved value: -"The question for kapoost. Plain text, max 1000 chars."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and delivers: async timing ('minutes, hours, or days'), rate limiting, returned ID, idempotent behavior with 'from', and recommendation to avoid duplicates. This is exemplary disclosure for a stateful async tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries operational value: action, return value, rate limit, polling path, and the critical 'from' dedup behavior. It is dense but not bloated, and the most important guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param async tool with no output schema, the description covers the invocation essentials: required question, optional context existence, stable 'from' behavior, rate limiting, and follow-up mechanism. The only notable gap is lack of any hint about what 'context' is for, and no detail on the response shape beyond an ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It richly explains 'from' and implicitly clarifies 'question' via the purpose sentence, but 'context' receives no semantic explanation. Two of three parameters are adequately covered, which is decent but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Submit an async question to kapoost' and says it returns an ID. It clearly distinguishes itself from siblings like fetch_answer by framing this as the submission side of an async exchange.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use this to submit an async question, then poll fetch_answer later; rate-limit is disclosed; the 'ALWAYS set from' instruction gives a strong prescriptive rule. It does not explicitly name alternatives it should be preferred over, but the async workflow context is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.