@tasque/piazza-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct Piazza resource and action: courses, posts, users, follow-ups, answers, endorsements, and moderation flags. Even similar-appearing tools like get_course_stats vs get_course_info are clearly differentiated by their descriptions.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_courses, create_post, mark_resolved). Minor variation between get_ and list_ is conventional and predictable.
Tool Count4/5
22 tools is slightly above the typical 3-15 ideal range, but each tool corresponds to a meaningful Piazza interaction. The number is justified by the breadth of the platform's features, though a few could potentially be combined (e.g., mark_read with edit_post).
Completeness5/5
The tool set covers the full lifecycle of Piazza posts (create, read, update, delete, moderate), user browsing, and course info. It includes answer posting, follow-ups, endorsements, and status management, leaving no obvious dead ends for common workflows.
Average 3.7/5 across 22 of 22 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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, the description carries the full burden of behavioral disclosure. It merely states the action without revealing side effects, authentication requirements, irreversibility, or any other behavioral traits beyond what the tool name already implies.
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, clear sentence that conveys the core functionality without any redundant or extraneous information. It is efficiently structured and easy to parse.
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 presence of many sibling tools and the lack of annotations or output schema, the description is too minimal. It does not explain the difference from create_reply, describe expected outcomes, or note any constraints, leaving significant gaps for correct invocation.
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 all four parameters (100% coverage). The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate given the schema already documents each field.
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 (create), the resource (follow-up discussion), and the context (existing Piazza post). It is specific enough to distinguish from general post creation, though it does not explicitly differentiate from create_reply or other sibling 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?
No guidance is provided on when to use this tool versus alternatives like create_reply or create_post. The description does not mention prerequisites (e.g., post must exist) or contextual scenarios, 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.
Behavior2/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 mentions 'Get' which implies read-only, but does not explicitly state that it is safe, what permissions are required, or any side effects. It also does not disclose potential limitations such as data freshness or aggregation details.
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, front-loaded with the verb 'Get', and includes the key output categories. No wasted words.
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 read tool with one parameter and no output schema, the description provides a reasonable overview. However, it lacks details about return format, pagination, or any usage context. Given the absence of annotations, it is minimally viable but not 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 fully documents the single parameter 'network_id' with a clear description. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline 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 retrieves statistics for a Piazza course, listing specific data types (participation, post counts, response metrics). It uses a specific verb and resource, but does not explicitly differentiate from the similar sibling 'get_course_info', which could also be seen as stats-related.
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. It does not mention when 'get_course_stats' would be preferred over 'get_course_info' or other read tools. The context is only implied by the tool name and description.
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 full burden for behavior. It conveys a read-like filtering action but does not disclose whether it modifies state, requires authentication, or how results are paginated. It also does not mention any prerequisites beyond the schema's required network_id.
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, tight sentence that front-loads the action and lists all filter dimensions. It contains no filler or repeated information from the schema.
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 filter tool, the description covers the basic purpose but omits return format, pagination, or any usage notes. Since there is no output schema, a bit more detail about what the filtered feed contains would improve completeness, though the core filtering behavior is adequately conveyed.
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 each parameter having a description, so the schema already explains the parameters. The description adds little beyond listing the filter criteria, which are already represented in the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Filter' with the resource 'post feed' and enumerates three specific filter dimensions (folder, following status, unread status). This clearly states the tool's function, though it does not explicitly contrast it with sibling tools like search_posts or get_feed.
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 tool should be used when filtering the feed by folder, following, or unread status, but it offers no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the choice between this and get_feed/search_posts to inference.
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?
The description discloses only the core effect without any behavioral context such as permission requirements, reversibility, or side effects. With no annotations provided, this is a significant gap 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 a single, front-loaded sentence with no redundancy or filler. It communicates the core purpose efficiently.
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?
The tool is simple, but the description lacks behavioral context beyond the action itself. While the schema covers all parameters, the absence of annotations and output schema means the description should provide more context about expected outcomes or constraints; it does not.
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 complete descriptions for all three parameters (network_id, post_number, resolved). The description adds no additional parameter semantics, so the baseline of 3 applies.
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 the specific verb 'mark' with the resource 'Piazza question' and explicitly states the two possible states (resolved/unresolved), clearly distinguishing it from sibling tools like mark_read or mark_duplicate.
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 regarding when to use this tool versus alternative mark tools, prerequisites, or context. The description only states the action, leaving the agent to infer usage from the name and siblings.
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 states the action 'reply' without mentioning side effects, permission requirements, reversibility, or the anonymous parameter's effect. No contradictions exist, but key behavioral context is missing.
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, direct sentence that is front-loaded with the core purpose. It contains no redundant information and is appropriately sized for the tool.
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 complete schema coverage, the description is sparse on context. It lacks mention of prerequisites (e.g., an existing followup_id), permissions, relationship to create_followup or create_post, or any output/response behavior. Since there are no annotations or output schema to compensate, the tool description is 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?
Schema description coverage is 100%, with each parameter already described in the schema. The tool description adds no additional parameter-level semantics beyond what the schema provides, so it remains at the baseline score.
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 'Reply to a follow-up discussion on a Piazza post' uses a specific verb and resource, clearly distinguishing this tool from siblings like create_followup (which creates a new follow-up) and create_post. The purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when replying to an existing follow-up) but provides no explicit guidance on alternatives, exclusions, or prerequisites. It does not mention that the followup_id must exist or differentiate scenarios where create_followup would be 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?
Annotations are absent, so the description carries the full burden. It merely states what the tool does without disclosing potential rate limits, authentication requirements, or any constraints on the returned profile data. No detail about response structure or error conditions is given.
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 redundant information. Every word contributes to understanding the tool's purpose and scope.
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 read tool with two well-documented parameters, the description is minimally adequate. However, without an output schema, it leaves unspecified what 'profile information' contains and whether any access restrictions apply, which is a notable gap.
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 describes both parameters (user_ids and network_id) with 100% coverage. The description adds no extra meaning beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'profile information for specific users in a Piazza course by their user IDs,' which distinguishes it from siblings like list_users (which likely returns all users). The resource and scope are specific and unambiguous.
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 when needing profiles for specific user IDs, but it does not explicitly state when to prefer this over list_users or other alternatives. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer.
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 explains the action ('endorse it') but does not mention permissions, reversibility, or side effects, which is a gap 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 concise sentences, front-loads the primary action, and adds a useful analogy to the Piazza button without any 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?
The tool is simple and the schema covers parameters well, but given no annotations, no output schema, and no explicit usage guidance, the description is adequate but leaves some gaps about effects and when to 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?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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 an answer or follow-up as good answer') and the specific resource it acts on. It also distinguishes this from sibling tools like remove_answer_good, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: if you want to endorse an answer or follow-up, this is the tool. However, it does not explicitly contrast with alternatives like remove_answer_good or mention when not to use it.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the primary effect (linking the duplicate to the original) but fails to disclose other important behaviors such as whether the action is reversible, whether permissions are required, or whether the original post is also affected. This is a significant transparency gap 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 short sentences that front-load the core action and its result. Every word contributes value, with no filler or redundant information.
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?
The tool is relatively simple with low complexity, and the schema fully documents parameters. However, with no annotations and no output schema, the description leaves behavioral gaps (reversibility, permissions, side effects) that are relevant for a mutation tool. It is adequate for the basic purpose but not fully 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema; it only mentions duplicate and original concepts that are already defined in the parameter descriptions. The optional 'message' parameter is not referenced in the 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's function: 'Mark a Piazza post as a duplicate of another post.' The verb 'mark' and resource 'duplicate' are specific and the action is distinct from sibling tools like mark_resolved or mark_answer_good. It also adds the useful detail that the duplicate will link to the original.
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 to use the tool (when a post is a duplicate of another), but it does not explicitly state when not to use it or mention alternatives. There is no exclusionary guidance, but the context is clear enough that the usage scenario is inferable.
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?
Without annotations, the description must disclose behavioral implications, but it only states the action. It does not mention idempotency, whether the read state is scoped to the current user, or any side effects on unread counts, leaving room for ambiguity.
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, direct sentence with no unnecessary words. It is front-loaded and immediately understandable, earning full marks 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?
This is a simple mutation tool, but it lacks details about user scope, side effects, or return behavior. Given no output schema and no annotations, the description is minimally adequate but not fully complete for a state-changing action.
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 schema carries the full semantic load. The description adds no extra parameter details, meeting the baseline expected since schema coverage is high.
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) on a specific resource (Piazza post) with a precise outcome (as read). It is easily distinguished from sibling tools that handle creation, deletion, or retrieval, 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 does not explicitly provide usage context or alternatives. However, the purpose is self-evident, so when to use it is implied, though no exclusion or comparative guidance is given.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action (create) and object (post), but does not reveal side effects, required permissions, notification behavior, or reversibility. This is a significant gap 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 a single, concise sentence that directly states the purpose. It contains no fluff, filler, or repetition, earning a high score for conciseness.
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 there is no output schema and no annotations, the description should explain what happens after creation (e.g., returns post ID, appears in feed, requires authentication). It does not. It only states the basic purpose, which is inadequate for a 6-parameter mutation 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 input schema has 100% description coverage for all 6 parameters, including an enum for 'type'. The description adds no extra parameter information beyond what the schema already provides, so it stays at the baseline of 3.
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 the specific verb 'create' and resource 'post', and clarifies the post types (question, note, poll) as well as the scope ('in a Piazza course'). This clearly distinguishes it from sibling tools like create_reply and create_followup, which are for other content types.
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 gives clear context: a top-level post in a Piazza course. It implies this is for starting a new thread, not for replying (sibling tools cover those). However, it does not explicitly mention when not to use it or name alternatives, so it stops 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context about sorting and pagination, and the 'Get' verb implies a read-only operation. However, it does not explicitly state that it is read-only, nor does it mention authentication requirements, rate limits, or any potential side effects or limitations.
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 exceptionally concise: two short sentences. The main purpose is front-loaded in the first sentence, and the pagination detail is secondary. No unnecessary words or repetition; every word earns its place.
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 feed retrieval tool with full parameter schema coverage, the description is adequately complete. It states what the tool does (gets recent posts), the sorting behavior, and pagination support. It omits explicit return format or authentication details, but these are not critical given the straightforward read-only nature and the absence of an output schema.
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 100% coverage, with clear descriptions for limit, offset, and network_id. The description's mention of pagination adds context but does not go beyond what the schema already documents. Given the high schema coverage, a baseline score 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 (Get) and resource (feed of recent posts in a Piazza course), with additional detail on sorting ('sorted by most recently updated') and pagination. This distinguishes it from siblings like get_post (single post) and search_posts/filter_posts (filtering/searching), 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 explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or reference sibling tools such as search_posts or list_courses, leaving the usage context entirely implied.
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?
No annotations are provided, so the description must carry the full behavioral burden. It discloses the return format (post numbers and subjects) but lacks important details such as search scope (e.g., whether it searches titles, content, or both), case sensitivity, pagination, or result limits. This is a minimal level of transparency for a search 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 sentence, front-loaded with the action and resource, and contains no filler or redundant content. Every word contributes to the purpose and output.
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 tool's simplicity (2 required parameters, no output schema), the description adequately covers purpose and return values. However, it omits search scope and result behavior, which would be helpful given the large set of sibling tools. Overall, it's nearly complete for a lightweight search 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 schema already describes both parameters with 100% coverage. The description adds only that the search is 'by keyword', which loosely maps to the 'query' parameter, but does not elaborate on the network_id format or any parameter-specific constraints beyond what the schema provides. Thus, the description adds minimal value over 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 action ('Search for posts') and resource ('in a Piazza course'), with a specific mechanism ('by keyword'). It also describes the return value ('matching posts with their numbers and subjects'), which distinguishes it from siblings like get_feed or get_post.
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 use for keyword-based search in a course, but does not explicitly contrast with alternative tools such as filter_posts or get_feed. It provides no when-to-use or when-not-to-use guidance, leaving the selection inference to the agent.
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 for transparency. It simply states 'Get detailed information' and lists content areas, but does not disclose potential error conditions, permission requirements, response format, or any side effects (e.g., read-only guarantees). This is minimal behavioral disclosure for a tool with no annotation support.
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 that efficiently communicates the tool's purpose and scope without any filler or repetition.
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 tool's simplicity (one required parameter, no output schema, no annotations), the description provides a reasonable list of what the info includes (folders, instructors, term, settings). It could benefit from mentioning that the network_id must be a valid Piazza course ID, but overall it is sufficiently complete for a basic read operation.
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%, with the only parameter network_id fully described in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
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 ('Get') and resource ('detailed information about a specific Piazza course/network'), and lists concrete contents (folders, instructors, term, settings). This distinguishes it clearly from siblings like get_course_stats and list_courses, which target different aspects.
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 sets clear context: use this tool when you need detailed information about a single course/network. It implies contrast with list_courses (for all courses) and get_course_stats (for statistics), though it does not explicitly name alternatives or exclusions.
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 must carry the burden of behavioral disclosure. The verb 'List' strongly implies a read-only operation, and the description clarifies the data scope. However, it does not mention permissions, pagination, or error behavior, leaving some behavioral ambiguity for a tool with no annotation support.
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 that conveys the essential purpose and output without unnecessary words. It earns its place and is appropriately sized for a tool with one parameter.
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 tool's simplicity (one parameter, no output schema), the description adequately explains what the tool returns: names, emails, roles. It does not explicitly state the return format (e.g., array), but 'List' strongly implies it. A small gap is the lack of detail about edge cases (e.g., empty course or invalid ID), but overall it is sufficiently 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?
Schema coverage is 100%: network_id is described as 'The Piazza network/course ID'. The description only restates 'Piazza course' without adding syntax, formatting, or usage details. With full schema coverage, the baseline of 3 applies.
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 ('List'), the resource ('all users'), and the specific roles covered (students, instructors, TAs). It also lists the returned fields (names, emails, roles), making it easy to distinguish from sibling tools like list_courses or get_user_profile.
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 to use this tool—when you need a complete user roster for a Piazza course—but it does not explicitly mention alternatives or exclusions. There is no guidance on when to prefer this over get_user_profile or list_courses, only an implicit use case.
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 must carry the full burden. It adds the useful context that the student answer is a collaborative wiki-style entry editable by any student, which implies updatability. However, it does not disclose potential side effects (e.g., overwriting existing answers), permission requirements, or error behavior, limiting transparency 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 followed by a relevant explanatory note. Every word contributes value, with no redundancy or excessive length.
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 tool's simplicity, the description plus schema adequately cover how to invoke it: the action, the revision parameter for edits, and the collaborative nature of the answer. The absence of an output schema is not a concern for this mutation tool. Lacks a few safety details but is reasonably complete for the task.
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 100% coverage with descriptions for all parameters, so the baseline of 3 applies. The description does not add further parameter-specific meaning beyond what the schema already conveys, such as the revision number semantics.
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: posting or updating a student answer on a Piazza question. It specifies the target resource (student answer) and distinguishes it from sibling tools like `post_instructor_answer`, 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 when to use the tool (for student answers on Piazza), but it does not explicitly contrast with alternatives such as `create_reply` or `post_instructor_answer`. No when-not-to-use guidance is provided, leaving room for ambiguity in tool selection.
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 must disclose behavioral traits beyond the action itself. It only states the removal action without mentioning permissions, idempotency, or behavior when the endorsement does not exist. This adds no extra context beyond the tool name.
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 of nine words, front-loaded with the action and object. No unnecessary details or repetition, making it maximally concise.
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 mutation tool with three well-documented parameters, the description covers the core purpose and parameter meaning through the schema. However, it omits behavioral details such as permissions or error conditions, though these are not essential for basic invocation. Overall, it is adequate but not exhaustive.
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 documents all 3 parameters with descriptions, achieving 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so baseline 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 uses the specific verb 'Remove' with a specific resource: 'good answer endorsement' from an answer or follow-up. This clearly distinguishes it from sibling mark_answer_good and other actions, leaving no ambiguity about what the tool does.
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 clear context for when to use this tool: when an endorsement needs to be removed. It does not explicitly name alternatives or exclusions, but the context is unambiguous given the sibling mark_answer_good and the action's specificity.
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 must carry the full burden of behavioral disclosure. It does state the core action (pin/unpin) and the positional effect, but it lacks details on permissions, idempotency, or potential side effects. Since the tool is simple and the behavior is mostly guessable from the description, a score of 3 is appropriate.
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 exactly two sentences, front-loading the action and providing a concise consequence. Every word earns its place; there is no fluff or repetition. This is an exemplary concise description for a simple tool.
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 toggling operation, the description adequately covers the purpose and effect. It does not describe return values or error conditions, but given the tool's low complexity and full schema coverage, these omissions are acceptable. A slightly richer note on permissions or idempotency would make it fully complete, but the current description is 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?
The input schema already provides descriptions for all three parameters with 100% coverage. The tool description adds no additional meaning beyond the schema—it simply restates the pin/unpin behavior already captured by the 'pin' parameter description. Thus the baseline of 3 applies.
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 with a specific verb and resource: 'Pin or unpin a Piazza post.' It also explains the effect ('Pinned posts appear at the top of the feed'), which differentiates it from sibling tools like get_post or create_post. This is a precise and unambiguous purpose.
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 the use case by stating the effect on the feed, but it does not explicitly mention when to use this tool versus alternatives. However, among the sibling tools, no other tool handles pinning, so the intended usage is clear. A dedicated alternative/exclusion note would push this to 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 provided, the description carries the transparency burden. It discloses the mutating nature ('Post or update') and the authorization requirement ('Requires instructor/TA privileges'). However, it does not explain effects like whether updating overwrites an existing answer, revision semantics, or other side effects, which would be useful behavioral context.
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 only two sentences, front-loaded with the primary action and resource, followed by the privilege requirement. Every word adds value, with no redundant or filler 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?
Given 5 parameters, no output schema, and no annotations, the description provides enough context for an agent to understand the tool's core purpose and constraints. It explains the action, target, and permission requirement, while relying on the schema for parameter details. Slightly more detail on revision behavior or idempotency would improve completeness, but the schema covers revision semantics.
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%, with every parameter (content, revision, anonymous, network_id, post_number) having a description. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score 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 uses specific verbs 'Post or update' and clearly identifies the resource as 'the instructor answer on a Piazza question'. It distinguishes itself from sibling tools like post_student_answer by specifying 'instructor answer' and instructor/TA privileges, making its unique purpose clear.
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 context by stating 'Requires instructor/TA privileges', which implies this tool is for authorized users providing official answers. It does not explicitly name alternatives like post_student_answer, but the privilege mention and 'instructor answer' clearly situate it relative to student-facing 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states that the action is destructive, cannot be undone, and requires privileges, covering the most critical behavioral traits. It could mention side effects on related content, but the key safety information is present.
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 exceptionally concise: two sentences with no filler. The main action is front-loaded, and the additional warnings about destructiveness and permissions earn their place.
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 two-parameter destructive tool, the description covers all essential points: action, irreversibility, and privileges. It does not explain whether the entire thread is deleted or just the single post, but given the tool's simplicity and the absence of an output schema, the information provided is largely 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?
The schema already includes descriptions for both parameters (network_id and post_number), achieving 100% coverage. The description adds no additional parameter-level semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: "Delete a Piazza post." It uniquely identifies this as a deletion tool among siblings, which all focus on creating, editing, or reading posts, so it stands out distinctly.
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 clear context for when to use the tool by warning that the action is irreversible and requires instructor/TA privileges. It does not explicitly name alternatives, but the destructive warning and permission requirement effectively guide appropriate usage.
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 full burden. It discloses that the tool edits title/content and requires at least one field, but it does not mention potential side effects, whether the post must exist, or what the response looks like. Some useful context but not comprehensive.
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, immediately states the core function, and includes a key usage constraint without any unnecessary detail. Excellent structure and economy.
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 mutation tool, the description covers the purpose and the main constraint. However, without an output schema or mention of the return value, the agent does not know what to expect after the operation, leaving a small gap in completeness.
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 schema already describes all four parameters (100% coverage). The description adds a meaningful cross-parameter constraint not present in the schema: the requirement that at least one of title or content must be provided. This adds 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 action ('Edit') and the resource ('existing Piazza post'), specifically targeting title or content. This distinguishes it well from sibling tools like create_post or delete_post.
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 implies use for modifying an existing post and adds a specific constraint ('must provide at least one of title or content'). However, it does not explicitly mention when not to use it or name alternative tools, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral trait: it returns the full post with all constituent parts. It does not mention read-only status, but 'Get' implies non-mutation. It lacks details on error handling or permissions, but for a simple read operation, the disclosure of return content is sufficient.
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 main purpose, and the second sentence adds a practical usage hint. No redundant or extraneous information.
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?
The description adequately covers what is returned and how to specify the post. It does not mention potential errors or access restrictions, but for a simple get operation with no output schema, this level is sufficient. The sibling tools are distinct enough that the tool's role is clear.
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% for both parameters, so the baseline is 3. The description repeats the example for post_number ('123' for @123) already in the schema and adds no additional semantic context for network_id 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 retrieves a full Piazza post, listing specific content like question body, answers, follow-ups, and endorsements. This distinguishes it from siblings like get_feed or search_posts by focusing on a single post by number.
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 clear context on how to use the post number (e.g., '@123') but does not explicitly mention when to use this tool over alternatives like search_posts or get_feed. It is implied that this is for retrieving a specific post by ID, but no explicit exclusions or alternative tool references are given.
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 behavioral disclosure. It unambiguously indicates a read-only listing operation ('List all...') and scopes it to the authenticated user. It also details the returned data. While it omits side-effect discussion, that is appropriate for a simple read operation, and there is no contradiction with 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?
The description is two short sentences, front-loaded with the action, and contains no fluff. Every word contributes: the verb 'list', the resource 'courses/networks', the scope 'authenticated user', and the output fields. This is an exemplar of concise structure.
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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description fully covers the necessary context: the action, the scope, and the return values. An agent can correctly invoke this tool without further clarification. It is complete for its intended use.
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 and the schema is empty (100% coverage vacuously). The description correctly ignores parameter details since none exist. The baseline for zero parameters is 4, and no additional explanation is needed.
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 a specific verb and resource: 'List all Piazza courses/networks the authenticated user is enrolled in.' It also specifies the return fields (names, IDs, terms, roles), making its purpose unambiguous and distinct from sibling tools that operate on individual courses or posts.
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 discovering the authenticated user's enrolled courses, which is a prerequisite for other course-specific tools. However, it does not explicitly contrast with alternatives like get_course_info or get_course_stats, nor does it state when not to use it. The usage context is clear but not explicitly differentiated.
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:

[![claude-piazza-mcp MCP server](https://glama.ai/mcp/servers/TylerFlar/claude-piazza-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TylerFlar/claude-piazza-mcp)

Score Badge

Copy to your README.md:

[![claude-piazza-mcp MCP server](https://glama.ai/mcp/servers/TylerFlar/claude-piazza-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TylerFlar/claude-piazza-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/TylerFlar/claude-piazza-mcp'

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