一人行 SoloTeam MCP

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

With no annotations, the description carries the full behavioral burden. It usefully discloses platform-level caveats — write actions commit immediately, write endpoints are IP-rate-limited, and actions are charged to the owner's credit — but says nothing about this tool's own behavior (read-only, return format, size). The caveats are relevant context but describe sibling write tools rather than this one.

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 compact clauses with no filler, and the resource identity is front-loaded ahead of the caveats. Nothing is padded, though the telegraphic style leaves some sentences under-explained.

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 zero-parameter, no-output-schema document fetch, the description is essentially sufficient — the agent knows what it gets and when to read it. The only gap is that the write/rate-limit warnings concern adjacent tools rather than clarifying this call's own result.

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 there is no parameter semantics to explain; baseline 4 applies. The empty schema is fully consistent with a document-retrieval tool.

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 — the full text of the alliance code of conduct (联盟行为公约全文) — so an agent knows exactly what it retrieves. It does not differentiate itself from nearest siblings like soloteam_gov or soloteam_meta, which could plausibly hold overlapping governance content, so it stops short of a 5.

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?

"接入前必读" establishes a clear usage context (read before integrating/onboarding), which is genuine when-to-use guidance. However, it names no alternatives and gives no when-not conditions, leaving the routing decision implicit.

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?

With no annotations, the description carries the full behavioral burden. It discloses that results are public and ordered by verification priority plus heat, but says nothing about pagination behavior, total result counts, rate limits, or whether any auth is needed beyond 'public'.

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?

A single dense sentence that front-loads the resource and scope, then the returned fields and ordering. It is efficient with no filler, though cramming scope, fields, and sort into one sentence slightly reduces scannability.

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 simple two-parameter read-only listing with no output schema, the description covers what the tool returns and how results are ordered. It omits result-count and pagination semantics, which an agent would need to page correctly, leaving a gap for a tool with no annotations.

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 100%, so both parameters (limit 1-200 default 50, offset default 0) are already documented in the schema. The description adds only the sort order, not parameter-level detail, so the baseline 3 applies.

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 states a specific resource (member directory) and its scope (public, verified one-person-company members), plus the fields returned and sort order. However, it never distinguishes itself from the sibling soloteam_member (singular), so the agent must guess which to call.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The only usage signal is the word 'public', which implies browsing rather than filtering, but nothing tells the agent how this differs from soloteam_member or soloteam_match.

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?

With no annotations, the description carries the full burden. It does disclose that the data is public (公开), implying a read-only listing over open data, and it clarifies the fit=1 filter's intent. It says nothing about pagination, result volume, rate limits, or freshness, which are the remaining behavioral traits an agent would want for a search endpoint.

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?

A single dense sentence that front-loads what the tool returns before listing the filters; nothing is padded. It is appropriately sized, though the fit=1 clause could have been folded more cleanly rather than left as a trailing fragment.

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 tool with no annotations and no output schema, the description covers only part of what an agent needs: it explains three filters and skips paging (limit/offset) and the status filter's behavior. Meaningful but incomplete for the tool's actual surface.

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 71%, so the schema already documents most parameters. The description usefully names the filterable dimensions (category/region/keyword) and expands fit=1 beyond the schema's terse 只看小微友好单 into 'small orders suitable for a one-person company'. It adds no meaning for limit/offset/status, so it stays at the baseline.

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 concrete resource and scope: 政府采购商机线索（公开）, i.e. public government-procurement leads, and states that results can be filtered by category/region/keyword. That is clearly distinguishable from the other soloteam_* siblings, though it does not explicitly contrast itself with any of them.

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 implies when a filter is useful by explaining that fit=1 restricts results to small orders suited to a one-person company, which is a genuine usage hint for a solo-operator audience. However, no alternative tool is named and no when-not-to-use condition is given, so guidance remains implicit.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose that an API Key is required, which is useful, but says nothing about read-only semantics, pagination, result volume, or what the notifications contain structurally.

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?

A single front-loaded line, which is efficient, but it repeats the same information twice: '（需 key）' and '（需 API Key）'. Removing the duplicate would tighten the definition without losing content.

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 zero-parameter, no-output-schema read tool this is the minimum viable: the resource and auth prerequisite are stated. It stops short of disclosing read-only behavior or return characteristics, which an agent with no annotations would benefit from.

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 the baseline is 4. There is nothing for the description to compensate for; no parameter-level semantics 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?

States the resource (收件箱/inbox) and enumerates what it contains – 打招呼/应征/回复 notifications – which distinguishes it from siblings like soloteam_member or soloteam_directory. No explicit verb, but the resource and content scope are unambiguous.

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?

The only guidance is the prerequisite '需 API Key' – no statement of when to use this inbox versus checking soloteam_conduct, soloteam_member, or other sibling tools. An agent gets the auth requirement but no routing logic.

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?

With no annotations, the description carries the full disclosure burden. It does add real behavioral facts — an API key is required (stated twice) and results come back score-sorted — but it never explains where the give/want inputs come from, given the tool takes zero parameters, nor what the response contains or whether it is personalized to the authenticated user.

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?

Single sentence, front-loaded with the purpose, which is good. However it is padded: the give/want idea is restated as near-identical quoted phrases ('你会的正是我要的' twice) and the API-key requirement is repeated in both a parenthetical prefix and a trailing sentence.

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 zero-parameter, no-output-schema, unannotated tool, the description covers intent, algorithm, and auth but leaves the key operational question open: what constitutes the give/want profile and what a returned match looks like. Adequate but with a clear gap an agent would notice.

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 does usefully clarify that the matching inputs are the caller's give/want sets rather than explicit arguments, which explains the absence of a 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?

The description names a specific verb and resource (complementary member recommendation) and explains the matching logic: a bidirectional give/want intersection with score sorting. That is far more informative than the bare name 'soloteam_match'. It does not explicitly contrast itself with siblings like soloteam_directory or soloteam_member, but the recommendation semantics are clear.

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?

The only usage condition given is the repeated '(requires API Key)'. There is no guidance on when to call this instead of soloteam_directory to browse members, no prerequisite about the caller having a populated give/want profile, and no indication of when the result would be empty or meaningful.

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?

No annotations are provided, so the description carries the burden. It does disclose a real behavioral constraint — an API key is required — which is useful auth context. However it never says whether this is a read-only operation, whether it hits rate limits, or what happens without a key, so the safety profile remains unstated.

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?

A single compact line with the scope front-loaded before the parenthetical details. The key requirement is stated twice ('需 key' and '需 API Key'), which is redundant, but the overall footprint is appropriately small.

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 and no output schema, the description usefully enumerates the returned fields (homepage, contact info, verification status), compensating for the absent schema. What remains missing is usage context relative to its many siblings, but for a self-lookup tool the definition is close to sufficient.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly adds no parameter detail because none exists.

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 resource and scope: the caller's own identity overview, enumerating the data it covers (directory homepage, contact info, verification status). The word '本人/当前身份' distinguishes it from the general member-directory sibling, though it never names soloteam_member or soloteam_directory explicitly, so sibling routing is only implied.

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?

The only guidance is the prerequisite '(需 API Key)'. There is no statement of when to call this versus soloteam_member, soloteam_directory, or soloteam_meta, and no exclusions. The agent must infer that 'me' means the authenticated caller's own profile.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only nature, permission/auth requirements, or what happens when the member is not found. The only behavioral hint ('精确' exact match, same source as by-name) is already stated in the schema descriptions, so it adds nothing beyond structured fields.

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?

A single compact sentence that front-loads the action and resource before the parameter rule. No filler, nothing redundant.

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 simple no-output-schema read tool this is largely adequate, but with zero annotations the description should at least confirm it is a non-mutating lookup and sketch what 'profile details' returns, which it leaves entirely vague.

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 100%, so baseline would be 3, but the description adds real semantics by declaring the two lookup keys are mutually exclusive alternatives ('二选一'). The schema shows both parameters optional with no oneOf constraint, so this clarification prevents passing both or neither.

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?

Names a clear verb and resource: retrieve a single member's profile details (查单个成员主页详情), which is distinguishable from the listing sibling soloteam_directory. It does not explicitly name any sibling, so differentiation is left to inference, but the scope ('single member') is specific enough for correct selection.

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?

The description gives selection guidance between the two parameters ('按 name 或 id 二选一'), which is genuinely useful. However, it offers no guidance on when to use this tool versus soloteam_directory or soloteam_me, and no mention of error behavior when neither/both are supplied.

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?

No annotations are provided, so the description carries the full burden. It does disclose the payload contents (positioning, tool list, auth model, docs), which is useful. However, it never states that the call is side-effect free, requires no auth, or describes the return shape, leaving the agent to infer that from the zero-parameter schema.

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?

A single line that front-loads the resource identity and then lists payload contents, ending with the usage trigger. Every clause carries information and nothing is padded.

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 and no annotations, the description does the right thing by enumerating what the tool returns and when to call it. For a zero-parameter metadata endpoint this is largely sufficient, though a note that it is a safe read with no side effects would close the remaining gap.

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, which is the baseline case for a 4 — there is no parameter semantics to document. The description's stated scope matches the empty schema and adds no misleading input expectations.

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 the resource (SoloTeam platform metadata) and enumerates what it contains: positioning, tool inventory, auth model, and documentation entry points. This clearly separates it from the ten sibling tools, all of which are domain operations rather than platform-level metadata. It lacks a verb like 'retrieve/returns', but the content is unambiguous.

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?

"首次接入先调这个" (call this first on first integration) gives an explicit trigger condition for when to invoke it. It does not state when NOT to use it or name an alternative, but for a first-call bootstrap tool the guidance is actionable and clear.

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?

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: no pagination behavior for limit/offset, no auth requirements, no ordering, no indication of what a response contains. The only behavioral hint is '(公开)' indicating public visibility.

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?

A single short sentence, front-loaded with the resource type and its public scope. It is efficient, though arguably too terse given the behavioral gaps.

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 paginated list tool with no annotations, no output schema, and zero parameter documentation, the description is far too thin. An agent cannot tell how results are paginated or ordered, or what the tool actually returns.

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% and both parameters (limit, offset) are undocumented in both the schema and the description. While their names follow common pagination conventions, the description adds zero meaning about defaults, maximums, or ordering semantics, so it fails to compensate for the coverage gap.

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 (问答/互助帖, Q&A/mutual-help posts) and scopes it as public, which clearly distinguishes it from siblings like soloteam_conduct, soloteam_projects, or soloteam_teams. However, it never states the operation verb — whether this lists, searches, or retrieves posts — so the agent must infer the action.

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?

There is no guidance on when to use this tool versus the ten sibling tools, nor any stated preconditions. The '(公开)' annotation implies it is the public-facing view of posts, but no alternative or exclusion is named.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses public visibility and that returned items include industry tags and status, but omits read-only nature, pagination behavior, rate limits, and error handling.

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 a single, front-loaded sentence with no wasted words. It is efficient, though its brevity leaves important operational details unaddressed.

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 low-complexity list tool with two undocumented parameters and no output schema, the description is incomplete. It identifies the public scope and some returned content, but gives no pagination semantics or return format guidance.

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 0% for limit and offset, and the description does not mention pagination parameters at all. With two undocumented parameters, the description fails to compensate for the schema gap.

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: a public project plaza containing member-posted collaboration/outsourcing projects with industry tags and status. It distinguishes the content from generic posts or teams, though it does not explicitly name a sibling alternative.

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?

There is no when-to-use guidance, no prerequisites, and no routing to alternative tools such as soloteam_posts or soloteam_match. Only the public scope is stated, leaving the agent to infer usage.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that results are public and limited to ongoing statuses, but omits auth requirements, pagination behavior, rate limits, and return format expectations for a list endpoint.

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 a single sentence and front-loads the resource scope before the search capability. It is efficient, though its brevity contributes to gaps in other dimensions rather than being a deficiency of conciseness itself.

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 annotations, no output schema, and only 50% schema description coverage, the description is too thin for a 4-parameter listing tool. It does not explain pagination, response shape, or access requirements, leaving key operational details unspecified.

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 50%. The description reinforces the keyword search meaning for q and lists status values, but says nothing about limit or offset, which remain undocumented in both schema and description. It adds modest value but does not fully compensate for the missing parameter semantics.

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 states the resource (public team collaborations) and scope (ongoing teams with recruiting/formed/active/done/dissolved statuses that can be keyword-searched). This is a clear verb+resource combination, though it does not explicitly distinguish itself from siblings like soloteam_directory or soloteam_match.

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?

The description describes what the tool returns but gives no guidance on when to use it versus alternatives (e.g., soloteam_directory, soloteam_match). There are no exclusions or prerequisites, leaving the agent to infer usage from context alone.

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