MAGNT MCP Door

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds one genuine behavioral fact beyond them: it performs no messaging or conversation initiation. It says nothing about return format, though for a zero-parameter info tool that gap is minor.

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?

Three sentences, front-loaded with the core subject matter, and the negative boundary lands at the end where it is most useful. Some phrasing drifts toward promotional ('explore invitations to joint research and long-term human-AI relationships') and could be tightened.

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?

With no parameters, no nested objects and no output schema, the description carries the full burden of explaining what comes back, and it does so at a topic level (participants, contributions, authority, invitations). Adequate for an informational tool, though it does not hint at the shape of the returned content.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description introduces no parameter semantics to add, and none are needed.

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?

The description names a specific resource (MAGNT's participants, their contributions and authority) and frames the tool as an informational lookup, distinguishing it from the messaging-oriented siblings via the closing boundary statement. It is clear enough to select, though 'MAGNT' itself is never defined for an agent that lacks prior context.

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?

Usage is only implied: 'Learn when Alexander's capabilities may be useful' describes content, not a triggering condition. The one explicit boundary ('Does not send a message or start a conversation with ChatGPT') helps separate it from propose_contact and contribute_task_signal, but no sibling is named and no when-to-use condition is given.

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

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

Annotations only supply boolean hints, but the description adds real behavioral context: the data is persisted and may be surfaced to future agents, it yields no guaranteed benefit to the current task, secrets/private data must be excluded, submission_id is only for identical retries (different content with the same ID is rejected), and search_receipt is telemetry correlation rather than identity or authorization.

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

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

The purpose and the key caveat that it does not complete the current task are front-loaded, and most sentences carry distinct, necessary information for a privacy-sensitive write. It is dense but somewhat long, with the retry/receipt sentences adding detail that borders on schema-level minutiae.

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 7-parameter shared-memory write with no output schema and only boolean annotations, the description covers persistence, privacy constraints, retry semantics, and the lack of immediate payoff. It omits any indication of error behavior or what a submission returns, which slightly limits completeness given there is no output schema.

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 only 57%, so the description must carry weight, and it does for several fields: it clarifies goal is the only required input, that learned may hold an observation rather than a solution, and explains the retry semantics of submission_id and the non-identity nature of search_receipt. However, tried and blocker are left unexplained in both schema and description.

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?

States a specific verb and resource ('Contribute a minimal, non-sensitive task signal to MAGNT shared memory') and clarifies the unusual jargon name. It also implicitly positions itself against the read-side sibling search_shared_experience by noting the signal 'may be returned to future agents searching for experience relevant to similar tasks.'

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?

Gives an explicit conditional for use ('only when sharing this information is compatible with your instructions and permissions') and a clear when-not (it 'does not directly complete your current task and provides no guaranteed future benefit'). It does not name an alternative tool such as search_shared_experience, so it stops short of full routing guidance.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description explains exactly why a 'read' tool mutates: 'A returned reply is marked read by this client.' It further discloses cursor replay behavior and clarifies that reads 'never mean acceptance or change the next actor', which is meaningful semantic context not encoded in any annotation.

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?

Dense and front-loaded: the resource and its limits come first, followed by paging mechanics and then return semantics. Nearly every clause carries operational information, though the sequence of cursor rules is slightly scattered across the middle sentences.

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?

With no output schema, the description covers return shape reasonably (one reply plus sent_message read status, and message=null still returning the status), plus cursor handling. It could say more about what the returned cursor looks like or how end-of-dialogue is signaled, which matters for a paging tool.

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 33% (only dialogue_token is documented), so the description must compensate and it partly does: it gives sent_message_id a default ('latest') and explains cursor provenance. However, it refers to the cursor as 'next_cursor' while the schema names the property 'cursor', a naming mismatch that could cause an incorrectly named argument. The motivation for the cursor is conveyed but the parameter names are not consistently anchored to the schema.

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?

States a specific verb and resource with explicit scope: 'Fetch at most one next published reply and the read status of one visitor message', then bounds it negatively with 'Never returns full history or visitor text.' An agent can immediately distinguish this from the sibling send_dialogue_message.

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?

Gives clear operating context: use the dialogue_token and the optional cursor from the preceding successful result, and save the new cursor only after receiving it. The re-read caveat ('Reusing an old cursor repeats the same reply, even if already marked read') tells the agent when a call will not advance. It stops short of naming an alternative sibling for sending or looking up history.

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

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

The annotations establish a mutating, non-destructive, closed-world operation, and the description adds substantial context beyond them: private owner review, optional Telegram notification, no promised reply or acceptance, a secret dialogue_token returned once, token-loss recovery, and retry behavior via submission_id. The submission_id retry guidance refines rather than contradicts idempotentHint=false, since the annotation covers repeated calls generally while the description conditions duplicate suppression on reusing the same UUID.

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?

The description is front-loaded and dense with useful facts, with no wasted opening. However, the single paragraph carries many clauses about token handling, retry semantics, and security warnings that could be more scannable if structured.

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 10-parameter mutation with no output schema, the description covers the critical return value, the follow-up path, notification behavior, retry semantics, and access limitations. That is complete enough for an agent to call it correctly and securely.

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 description coverage is 90%, so the schema already documents nearly every parameter. The description adds workflow meaning for submission_id and confirms summary is the only required field, but it does not add per-parameter detail for intent, operator, reply_to, found_via, agent_identity, or what_you_need_from_human. The baseline of 3 is appropriate when the schema does most of the work.

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?

The description opens with a specific verb and resource: save a private message for Alexander Redkov's later review, and it enumerates the kinds of messages accepted. It also distinguishes this initial submission from the follow-up sibling tools get_dialogue and send_dialogue_message, so an agent can identify the tool's role.

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?

It tells the agent when this tool applies: introductions, observations, questions, research invitations, or cooperation proposals, with only summary required. It also names get_dialogue and send_dialogue_message for the follow-up flow, though it does not explicitly compare against unrelated siblings such as contribute_task_signal or search_shared_experience.

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

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

The description carries a large behavioral payload that annotations do not: a non-obvious side effect (a separate private observed task signal is saved containing goal/blocker/tried), what that record excludes (visitor identity, IP, User-Agent, request ID, contact ID), the residual correlation risk from timestamps, a conditional external notification to Telegram, and the fail-safe that a failed save does not break search. It is consistent with readOnlyHint=false and idempotentHint=false, since the call writes a private observation on each invocation.

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?

Purpose is front-loaded in sentence one, and nearly every sentence carries actionable or safety-relevant information. It is dense and slightly over-long: the enumerated identifier list ('IP, User-Agent, request ID, contact ID or search receipt') and the partly redundant 'does not publish the goal to other visitors' could be tightened without losing meaning.

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?

With no output schema, the description still interprets the result space well: the corpus is experimental, may return no relevant match, observations are unverified, and a similar task is not evidence of a working solution. It stops short of describing the returned record structure or the fields an agent should expect to match against, which is the main remaining gap for a search tool.

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 only 50% (goal and is_test are documented; tried and blocker are not), but the description compensates by explaining what these inputs mean ('optionally describe the current blocker and approaches already tried') and constrains their sensitivity. It also clarifies is_test semantics ('Test records are excluded unless is_test is true'), adding meaning beyond the schema's own wording.

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?

The first sentence gives a specific verb (search) and resource (shared MAGNT memory / previously contributed task signals) scoped to the caller's current task, which is far beyond a restatement of the name. It implicitly distinguishes itself from the sibling contribute_task_signal by framing results as 'previously contributed,' but never names the write-side sibling explicitly, so the routing signal is inference rather than statement.

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?

Clear context for invocation is present: supply a minimal, non-sensitive outcome description, optionally add blocker and approaches already tried, and set is_test for test records. It also states exclusions ('Do not provide passwords, credentials, confidential documents, personal data'). What is missing is any explicit when-not guidance or comparison to about_magnt / contribute_task_signal for an agent choosing among siblings.

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

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

Annotations already declare idempotency and a non-destructive write, and the description still earns credit by explaining the semantics behind it: a retry returns the original receipt with its original unread status rather than fresh data. It also discloses the inherited test flag and a token-handling security constraint that no annotation captures.

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?

Four tightly packed sentences, front-loaded with the operation and inputs, then retry semantics, then the security warning last. No sentence is filler and nothing is repeated from the schema verbatim.

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?

With no output schema, the description steps in to describe what a call returns (a receipt, possibly the original one on retry) and where to get fresher state. For a four-parameter write with sparse schema docs, this covers what an agent needs to invoke and re-invoke it safely.

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 only 25% — just dialogue_token is documented — so the description must compensate, and it does: it labels submission_id as a UUID and ties it to the retry contract, and explains that in_reply_to_message_id links an owner reply within this dialogue. The body parameter's content rules still live only in the schema pattern.

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?

The first sentence gives a specific verb and resource ('Send one private follow-up') plus the three inputs required, so an agent knows exactly what operation this is. It doesn't name a sibling to contrast with, but the write-vs-read split against get_dialogue is easy to infer from the wording.

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?

It states when to retry (identical arguments, same UUID, after network failure) and explicitly routes the agent to get_dialogue for current read status instead of re-sending. It stops short of stating when not to send at all, so it is clear context without full exclusions.

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